I tested it and it works! I used the GE device type with cree bulbs and used smart lighting to turn lights on with motion from a z wave motion sensor. I also did the same but with a smartsense open/close sensor. I then plugged the ethernet cable out of the ST hub and both automation still worked! Good find indeed!

Just an observation…I use minimotes programed to turn on and set light level depending on the time of night. With the original cree DT if the bulb was manually set to 1% and then turned off, of I turned the light on with the minimote which sets it to 60% it would go to 60% immediately. What I’ve noticed with the GE DT is that the bulb turns on to the last % first then fades up or down to the new %. So pressing the minimote in the same scenario, the light turns in to 1% then ramps up to 60% in about 2 seconds. Minor, but it’s something I’ll need to get use to.

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?

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.

Continuing the discussion from What's the deal with Nest?:
Correct.
I was answering this question below in the global sense. i.e., There will always be the possibility of various benefits available to Official Device Handlers and SmartApps that are not available to un-certified Community Developed ones. At the moment, the local processing benefit is inapplicable to Nest in either case.
[quote="copyninja, post:26, topic:20406"] I'm trying to understand why community developed smart-apps/device types isn't enough. [/quote]
I'm not sure ST has guaranteed that community developed SmartApps/Device Types will be included in local processing right after certification. Yes, it may be included down the road, and this is not yet clear on how or what the process is to enable community develope…

… sync all DH’s and SA’s code for each person’s account at boot and whenever there’s a change in the code?

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.

I’m interested in local processing. However, I don’t know where to start.
How can I ;

find out if my hub supports local processing ?

how can I change my devices & apps to local processing ?

find out advantages/disadvantages ?

Thanks.

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.

Continuing the discussion from What's the deal with Nest?:
Correct.
I was answering this question below in the global sense. i.e., There will always be the possibility of various benefits available to Official Device Handlers and SmartApps that are not available to un-certified Community Developed ones. At the moment, the local processing benefit is inapplicable to Nest in either case.
[quote="copyninja, post:26, topic:20406"] I'm trying to understand why community developed smart-apps/device types isn't enough. [/quote]
I'm not sure ST has guaranteed that community developed SmartApps/Device Types will be included in local processing right after certification. Yes, it may be included down the road, and this is not yet clear on how or what the process is to enable community develope…

Continuing the discussion from What's the deal with Nest?:
Correct.
I was answering this question below in the global sense. i.e., There will always be the possibility of various benefits available to Official Device Handlers and SmartApps that are not available to un-certified Community Developed ones. At the moment, the local processing benefit is inapplicable to Nest in either case.
[quote="copyninja, post:26, topic:20406"] I'm trying to understand why community developed smart-apps/device types isn't enough. [/quote]
I'm not sure ST has guaranteed that community developed SmartApps/Device Types will be included in local processing right after certification. Yes, it may be included down the road, and this is not yet clear on how or what the process is to enable community develope…