FAQ: CONFIRMED: Local Processing - Working Device Handlers

Here is a list of the Device Handlers that are confirmed working with local processing (I personally tested that these show up in the “LocalDevice List”) as of Dec 8, 2017:

Device Type						Run Locally		Execute Commands Locally		Minimum HubCore Version

Aeon Home Energy Meter			TRUE			FALSE							n/a
Aeon Illuminator Module			TRUE			FALSE							n/a
Aeon Key Fob					TRUE			FALSE							n/a
Aeon Minimote					TRUE			FALSE							n/a
Aeon Multisensor				TRUE			FALSE							n/a
Aeon Multisensor Gen5			TRUE			FALSE							n/a
Aeon Outlet						TRUE			FALSE							n/a
Aeon Siren						TRUE			FALSE							n/a

Arrival Sensor					TRUE			FALSE							n/a

CentraLite Thermostat			TRUE			FALSE							n/a

Dimmer Switch					TRUE			FALSE							n/a

Fortrezz Water Valve			TRUE			FALSE							n/a

GE Link Bulb					TRUE			FALSE							n/a

LAN Hue Bridge					TRUE			TRUE							000.019.00012
LAN Hue Color					TRUE			TRUE							000.019.00012
LAN Hue Color Temperature   	TRUE			TRUE							000.019.00012
LAN Hue Dimmable				TRUE			TRUE							000.019.00012
LAN Hue Extended Color			TRUE			TRUE							000.019.00012

Nortek CO Sensor				TRUE			FALSE							n/a
Nortek Door Window				TRUE			FALSE							n/a
Nortek Keyfob					TRUE			FALSE							n/a
Nortek Panel Device				TRUE			TRUE							n/a
Nortek PIR Sensor				TRUE			FALSE							n/a
Nortek Smoke Sensor				TRUE			FALSE							n/a
Nortek Water Leak Sensor		TRUE			FALSE							n/a

SmartAlert Siren				TRUE			FALSE							n/a

SmartPower Dimming Outlet		TRUE			FALSE							n/a
SmartPower Outlet				TRUE			FALSE							n/a
SmartPower Outlet V1			TRUE			FALSE							n/a

SmartSense Garage Door Multi	TRUE			FALSE							n/a
SmartSense Moisture				TRUE			FALSE							n/a
SmartSense Moisture Sensor		TRUE			FALSE							n/a
SmartSense Motion				TRUE			FALSE							n/a
SmartSense Motion Sensor		TRUE			FALSE							n/a
SmartSense Multi				TRUE			FALSE							n/a
SmartSense Multi Sensor			TRUE			FALSE							n/a
SmartSense Open/Closed Sensor	TRUE			FALSE							n/a
SmartSense Temp/Humidity Sensor	TRUE			FALSE							n/a

ZigBee Dimmer					TRUE			TRUE							000.019.00012
ZigBee Dimmer Power				TRUE			TRUE							000.019.00012
ZigBee RGB Bulb					TRUE			TRUE							000.019.00012
ZigBee RGBW Bulb				TRUE			TRUE							000.019.00012
ZigBee Switch					TRUE			TRUE							000.019.00012
ZigBee Switch Power				TRUE			TRUE							000.019.00012
ZigBee White Color Temperature	TRUE			TRUE							000.019.00012

Z-Wave Controller				TRUE			FALSE							n/a
Z-Wave Device					TRUE			FALSE							n/a
Z-Wave Dimmer Switch Generic	TRUE			TRUE							000.019.00012
Z-Wave Door/Window Sensor		TRUE			FALSE							n/a
Z-Wave Garage Door Opener		TRUE			FALSE							n/a
Z-Wave Lock						TRUE			FALSE							n/a
Z-Wave Metering Switch			TRUE			FALSE							n/a
Z-Wave Motion Sensor			TRUE			FALSE							n/a
Z-Wave Relay					TRUE			FALSE							n/a
Z-Wave Remote					TRUE			FALSE							n/a
Z-Wave Sensor					TRUE			FALSE							n/a
Z-Wave Siren					TRUE			FALSE							n/a
Z-Wave Smoke Alarm				TRUE			FALSE							n/a
Z-Wave Switch					TRUE			FALSE							n/a
Z-Wave Switch Generic			TRUE			TRUE							000.019.00012
Z-Wave Water Sensor				TRUE			FALSE							n/a
36 Likes

Nice investigative work. :slight_smile:

3 Likes

I went through every one of the device handlers with a test device and verified if they show up in the LocalDevice List.

After working with support for months on getting local processing working, I am amazed that the Device Handler never came up and my incorrect use of Smart Lighting was supposedly the issue. After changing my Cree Bulb from “Cree Bulb” to “SmartPower Dimming Outlet”, I was able to locally process my light. In frustration, I went through every device handler so I know what DH’s I need to use to get local processing working. Not once was changing my DH suggested from support to help with my local processing issue and I figured it out through trial and error.

Anyway, hope this helps anyone with similar local processing issues. If your device in NOT using one of these device handlers, local processing will NOT work.

I’ll keep this post updated as things change with help from the community

7 Likes

A question to SmartThings staff:

If Smart Lights is the primary use of local processing, why is there only one bulb that’s supported; the “GE Link Bulb”? We are using dimmer and outlet DH’s to control our bulbs, why are Zigbee and Z-Wave bulb DH’s not being locally processed when that is the design of local processing? Strange that some Water Valves and Garage Doors are locally processed and not 90% of the light bulbs DH’s…

4 Likes

Want to know the beautiful irony about that as well? GE Link bulbs aren’t even on the list of officially supported devices whereas the Cree Connected bulbs are… which don’t run locally as I understand it.

5 Likes

This is excellent work! Thanks for sharing it. It would be great if you could add it to the community – created wiki, as then others could add additional devices later as well. :sunglasses:

http://thingsthataresmart.wiki/index.php?title=ThingsThatAreSmart_Wiki

4 Likes

Yeah this is great! I’ve been using the GE Link Bulb with my Cree’s for local processing for a while. Crazy, just crazy…

1 Like

I’m curious. What are the benefits of local processing? My cree bulbs respond in under a second as is, and without an Internet connection I can’t trigger devices connected to smartthings even with my minimote connected to my ST hub. So what’s the big plus of local processing?

Also, I changed my cree bulbs to the device type you suggested and I’m not sure what happened but my Iris open/close sensor (zigbee) on my front door started going haywire which leads me to wonder if the device type you recommended affects the zigbee repeater in the cree bulbs as the door sensor isn’t very close to my hub. Changing the device type back resolved the issue as well.

1 Like

There are two big theoretical pluses to local processing:

One) local processing should run faster because it doesn’t have to go out to the cloud and come back

Two) local processing will continue to run even if the SmartThings cloud is unavailable

However, there’s an old engineering saying:

in theory, there isn’t much difference between theory and practice, but in practice there usually is. :wink:

Many people have reported that their locally operating devices ran slower than their cloud processing devices. It may be that the hub’s local processing just isn’t very efficient.

The second benefit does apply. It’s a very limited number of devices, and you won’t be able to do anything with the mobile app on your phone if the cloud is not available to your hub (even if your phone and hub are on the same local network), but it’s a feature that is important to some community members.

2 Likes

You could try the GE Link Bulb device type or Dimmer switch but I haven’t noticed that myself. I have a single Cree bulb and 4 Iris 3326-L motion/light sensors and have had no issues after changing the DH to SmartPower Dimming Outlet on the Cree.

Advantages for me with local processing:

  • My Iris motion sensors immediately turn on the light. The light is on a staircase and a 1 second delay is longer than I’d like. I saw improved performance (less delay) using local processing.

  • If internet drops or SmartThings is not triggering routines due to issues with the platform (which is rather common these days), my lights turn on every day at 6AM regardless. I am not reliant on the stability of the ST cloud or my Internet connection for my lights to turn on at their set times.

2 Likes

OK. I tried the ge device type and it works without any issues. Re local processing and scheduling, does turning on a light when there’s motion also work should you lose Internet connection?

Right now, the only thing that runs locally are smartlighting automations which use only device type handlers which also run locally. No custom code either smart apps or device type handlers) runs locally. Routines do not run locally. Notifications, including push notifications do not run locally. CORE does not run locally.

So if the motion sensor handler runs locally, the light handler runs locally, and you connect them with smart lighting, and there are no other non-local devices referenced, it should run locally.

https://support.smartthings.com/hc/en-gb/articles/209979766-Local-processing

Are you just updating the *type in the IDE? Is that enough or must I re-setup the bulb?

It should be enough to just update the type. Go to your IDE link /localDevice/list to confirm.

For example: https://graph-na02-useast1.api.smartthings.com/localDevice/list

I’m not home now, but using the GE device type with the cree bulbs and a
motion sensor with a locally processed device type, and automation done
with smart lighting, the automation should still take place even if I lose
Internet connection?

Different customers will have their accounts on different “shards”. If you sign into a shard that your own account is not associated with, you will be allowed to sign in, but the list will look blank. :disappointed_relieved:

The community created wiki keeps the list of all the possible shard links so you can find the one your own account is on. :sunglasses:

http://thingsthataresmart.wiki/index.php?title=FAQ

Thanks. It worked. The link to the local device list in the documentation gave me an empty list. . . …

At the present time there are three possible links depending on which shard your account is associated with. There will probably be more in the future.

The community – created wiki keeps a list of all the possible links so you can find the one your own account is on. :sunglasses:

http://thingsthataresmart.wiki/index.php?title=FAQ

1 Like

Sadly, I checked the list of apps that run locally and it’s empty.

https://graph-na02-useast1.api.smartthings.com/localInstalledSmartApp/list

They must all include nonlocal devices.

At present, There is only one thing that could be in a local smartapps list: smart lighting automations.

No other smartapps run locally. No custom code runs locally, but also nothing else from the marketplace.

It has to be a smartlighting automation and it can only include devices with device handlers that also run locally.