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: