Using smart lighting I setup my minimotes to run locally! This works with the GE DT with the Cree Bulbs. I can turn lights on and off even without the hub having a network connection. I have 2 tp-link smart switches I use for 2 fans and a z-wave dual relay that I use on a ceiling fan. Those are the only devices that don’t run locally for me now.
This is all intriguing to me, if so much can be run locally, without lag or issue, why is so much being processed over the Internet by force?
SmartThings was originally designed as a cloud-based architecture. Everything which runs locally has to be pushed out to every single hub as part of the hub firmware. That seems to be the biggest reason why it’s so limited right now.
Been thinking about it, and while I understand having main device types and officially supported devices in the firmware, couldn’t they simply make the hub sync all DT’s, DH’s and SA’s code for each person’s account at boot and whenever there’s a change in the code? I know what I’ve said sounds very simplistic but it should still be easier than processing everything in the cloud for all customers. The code used by my devices should take up a tiny amount of memory and while some people have a lot of devices, they have a lot of the same device type like 10 cree bulbs for example. Plus the hub has usb ports. It could download all the necessary code for my individual hub to an encrypted file on a USB flash drive which is kept in sync with the cloud and is loaded into memory at boot.
Again, I know it’s simplistic but sometimes a simple approach can work lol.
Anyhow, I’ll try not to write many more of these long posts in this thread (lol) but thanks to the OP for his time doing trial and error. This has made my ST experience much better as I used to worry about my fiance being home and there’s an Internet issue and her not being able to operate the lights and me in turn getting cussed out lol.
There are two ways this can work with the cloud element. All actions are carried out on the device, with all the software downloaded to it, then when something happens it updates the cloud. This means the cloud is just a check/balance thing, and would allow external stuff, ifttt, etc. I wish it was this way.
The second way is to have the cloud be the conductor, with only the bare essentials happening locally. This wouldn’t work with everything on the device, and trying to have logic on it as well, the delay to the cloud and back would cause all manor of havoc.
I would LOVE all the DTH’s to be in the device, and CoRE ;), but honestly I don’t see that happening, too many more moving parts and possible troubles.
Here’s the discussion thread for the details of local processing. I agree we shouldn’t clutter this thread with those.
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
That was the originally intended design, but couldn’t be implemented. Instead, the Hub uses a monolithic firmware of sorts that has all supported local code hard-compiled so it is the same for everyone.
But that makes it too big (and risky) to include arbitrary DTHs and SmartApps and, so far, no way to customize for individual customers.
If you have the V2 version of the hub (The current model), it supports a very limited amount of local processing. The V1 version of the hub does not support local processing at all.
The only app that can run locally at present is the official smartlighting feature, and then only if that Smart lighting automation is using devices that have a device type handler which is eligible to run locally and not using any device type handlers which are not eligible to run locally. See the list at the top of this thread for the ones that are eligible to run locally.
Also, some of the smart home monitor features run locally, but not all of them.
Nothing else runs locally. No custom code, no custom device type handlers, no other Smartapps.
If you set up a smart lighting automation that uses only devices using the device type handlers mentioned at the top of this thread, it should run locally. That’s it.
To keep from cluttering up this FAQ thread, I suggest taking any follow-up questions (other than the specifics of which device type handlers run locally) to the discussion topic for local processing: