SmartThings Community

FAQ: CONFIRMED: Local Processing - Working Device Handlers


(ilker Aktuna) #41

ok. but if there is a list I can see within my own devices , I want to look at them.
how ?


#42

Follow the link I already gave you. It will tell you exactly what to do.

Here it is again.

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


#43

Looks like the latest GIT commits are starting to add local/cloud processing notes in the code. Should make this easier to keep this list updated in the future:

Also a number of the listed DTH’s in my original post are now depreciated:

Removed the following locally processed devices as they no longer exist/depreciated after CHANGE-751 applied in GIT above:

CentraLite Dimmer
SmartSense Motion/Temp Sensor
SmartSense Open/Closed Accelerometer Sensor


(Jimmy) #44

Does this mean the SmartSense Motion sensor no longer runs local?!


#45

No, it’s the ss motion/temp sensor. Please refer to my first post for the list of local device types that are working.


#46

I have a quick question about local processing. I just found out that my Z-Wave Dimmer Switch is cloud only and not local. However, I took a quick look into the Dimmer Switch device handler and I cannot see any significant differences between the two yet Dimmer Switch is local capable. What makes one local capable and the other cloud only?

Also, if we implement a custom device handler, does that mean we that these devices is cloud only?

Thanks!


#47

The only device type handlers which can run locally are the ones that the SmartThings staff have decided to include in the firmware update that goes to everyone. They haven’t told us one way or another about why they choose one or whether they’ll be adding any more overtime. Except that they have said that they would like to eventually allow each customer to be able to run their choice of custom code locally, but we’re nowhere near that yet.

At the present time, any custom code, either a smart app or a device type handler, will have to run in the cloud and is not eligible to run locally.


(Michael Hess) #48

Try st dimmer dht’s. I use a number of them on “other” devices and they work fine, the generic zwave ones for example.


#49

Huh, you’re totally right. I just switched them to Dimmer Switch handler and it works. It’s really odd that we can’t pick and choose what local handlers we want in our personal hub. I would make sense since I won’t necessarily have most of the available local devices in my home.


(Michael Hess) #50

They are currently baked into the firmware. My guess is they never partitioned the internal storage for a user accessable partition. Maybe someday they’ll let us put a check next to the dht’s we really want…


#51

So let me see if I have this straight.

  1. Devices that support and are recognized as Local Devices should process faster. I’m assuming this means if you use the SmartThings application to turn a switch on/off or dim a light up/down it will occur quicker than a switch or dimmer that doesn’t support local processing. Will that also update the UI quicker? You know sometimes when you dim a light, the light might dim but then it takes a second to update the UI to show that you dimmed the light from 75% to 25%.

  2. If the Device and the SmartApp both support Local Processing and they are both recognized that way, than the SmartApp should process faster and should still execute when your hub does not have access to the SmartThings cloud.

  3. Since the SmartThings application requires access to the SmartThings cloud, even though you have Local Devices you won’t be able to control them with the application without access to the Smartthings Cloud. This one really disappoints me.

So is this correct?

One of the reasons I am asking is that I’ve installed a bunch of custom Device Handlers on Dimmers thus making them non-local. I’m trying to decide if I should revert them back to their native Device Handlers so they process locally.

Thanks again for the support of this great community.


#52

Unfortunately, while the speed issue would make sense technically, it has not always been true in the past in the actual SmartThings implementation . Sometimes the device handlers which are running locally appear to process more slowly than the ones that run in the cloud.

What local processing will absolutely give you is the ability for smartlighting (the official feature, which is the only smart app which currently runs locally) to operate even if the SmartThings cloud is unavailable.

So if the Internet is out at your house or the cloud itself is down, your local lights can still turn on and off by a local motion sensor.

Please take any additional follow on questions about how local processing works in ST to the following thread, so that we can keep this FAQ just for the list of device type handlers. :sunglasses:


(John) #53

I was under the impression that the 'Fibaro Motion ZW5" was a local device…am I wrong on that? Would I have to change the device type to “Z-Wave Motion” in order to get it to be local?


(Scott) #54

What SmartApps run local other than Smart Lighting?


#55

A few parts of smart home monitor, and that’s it. (But you can’t arm or disarm smart home monitor locally. )

No routines, no other smartapps from the marketplace, no custom code, no core, and the official mobile app cannot communicate with the hub unless the smart things cloud is available.

Just smart lighting limited to those device type handlers that are eligible to run locally, and some smart home monitor stuff.


#56

So after poking around and making some adjustments, I can see that I am on server 1 for my locally installed devices (and my device list is much larger now that I’ve changed my Cree bulb type… THANK YOU for this… all works well as you stated). My concern is that when I check locally installed smart apps from the wiki page, I can look even on all 3 servers and nothing shows up at all on any of them.

The odd thing is when I look on the iPhone app, it shows:
Button Controller (I believe this is the Aeon remote)
IFTTT
Logitech Harmony (Connect)
Nest Manager
Smart Lighting

When I go into the IDE under My SmartApps, I have:
bravenel: Rule
bravenel: Rule Machine
tonesto7: Nest Manager

Even more strange, I don’t use the rule or rule machine at all, so I will likely just remove those and when I go into My Device Handlers, I see both a dianoga Nest Thermostat (which is the “old” one I didn’t think I was using anymore that appears to be active on my hub and that entire line is green) and I also have all of the various tonesto7 Nest, all of those lines are red and it doesn’t look like it has an active session on my hub (right column) however it works in the app as I would expect it to and I can tell it’s using the new one, not the old one.

I am utterly confused… so even though I use SmartLighting for all of my lighting rules, it doesn’t appear in the IDE… what exactly does this mean and is there something I can do or have to do to fix this? I’m so confused at this point as I’m unsure why the iPhone app and IDE don’t seem to match up at all. BTW, everything through IFTTT, Logitech Harmony, etc. all work just fine… so why don’t they show up in the IDE and why do I have red vs. green line items in the device handlers? Thanks.


#57

Okay, sorry for the dual post… I didn’t realize that I had to check boxes under my home location under hello home to allow it to be executed locally… after I checked all of the boxes for smart lighting and clicked update, now when I look at my locally installed smart apps from the Wiki page, I see all of my smart lighting in the list. So I will test later with unhooking my network cable and seeing if these actions still execute. I still am VERY confused with the rest of my previous post though.


#58

Smartlighting is the only smart app which can run locally (plus a few bits of smart home monitor), so you wouldn’t expect to see anything else.

And the only smart lighting automations which can run locally are those which only refer to device type handlers which are eligible to run locally. If you include even one other device type handler, such as one for Hue or any custom code, it disqualifies the entire automation from running locally.


#59

Thanks… yes, I see now once I checked the boxes that it looks how I would expect, only the qualified devices and smart lighting apps… so THAT must be running correct.

In regards to the “mismatch” I am seeing with smart apps when clicking through the IDE and looking on my iPhone, is that to be expected?


#60

I also figured out the red vs. green… red is the code on GitHub is newer than what was locally installed… when updated, it turns the red text to black, then I re-publish it and it looks good. The green was custom code I added (not from GitHub) that is running.

I still don’t understand why in SmartApps I see something completely different on the iPhone app vs. on the IDE though.