Continuing the discussion from What's the deal with Nest?:
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 developed stuffs to run locally.
Correct me if I’m wrong, but even not all SmartApps and Device Handlers developed by SmartThings will execute locally. Only whitelisted apps will, of which there’s currently only one - Smart Lights. Also, it will execute locally if, and only if, all devices it’s hooked up to are also whitelisted for local execution.
It is also my understanding that in order to execute locally, SmartApps and Device Handlers must be bundled with the hub firmware and downloaded to the hub during firmware upgrade.
Yes… But obviously only “official/approved” Device Handlers and SmartApps are candidates for whitelisting, and still, SmartThings is likely to want to whitelist as much as optimal (ie., rarely used SmartApps or special odd Devices are a waste of memory, but popular ones are worth offloading from the Cloud).
Yes… Local execution is unfortunately currently also contingent on the entire set of Devices being local as well. It would be nice if they could hybrid within one SmartApp, but difficult to decide what to do if Internet is down or extra latent.
Yes… The announcement that “local Devices and SmartApps” are only distributed by a firmware update is really really disappointing as it fundamentally reduces flexibility. Different customers use differ sets of Devices and SmartApps and it is inefficient to push everything to everyone. This architecture makes modular / isolated testing difficult too. I guess even with the many months delay, SmartThings was just unable to come up with a reliable way to do modular distribution or a “cache model” that was implied by @hagins during Developer Call. I’m sure that there are good reasons and serious complications, but… Thought ST Engineers were geniuses.
BTW: WigWag has also proposed a modular caching architecture. I wonder if they manged to get it working.
.4 Another major remaining weakness is no ability for the client App to connect locally (and other local APIs). But not a surprise.
That is disappointing. Where was that announced? I must have missed it.
In this post.
Bummer. I couldn’t make it tonight.
This seems promising that he said that this packaging with the hub firmware is the “current limitation”. That sounds like it is not the permanent plan, right?
In the case of the Smart Lighting app it’s not as bad as you would think, as it’s a parent child app.
So the execution criteria (approved local devices), is applicable within each separate child automation.
Meaning the entire parent app and all of it’s children aren’t disqualified should a cloud/non local device exist within one of the automations.
Only the specific automation containing the non local device(s) are excluded.
Yes… There are a lot of potential improvements that will not require new hardware and are in absolutely unpublished plans.
Which means that there is no way to estimate when these features will be deployed. Jeff Hagins mention various features with November timeframe and others with “early next year”… I would double to quadruple the length of time before we see most of them, if ever.
I understand (and applaud) the desire for security but the path they chose leaves me without a reason to upgrade to the v2 hub. Half of my devices are from my homegrown adt integration smartapp and it sounds like that it will never be possible to run locally. If they would simply let me designate a smartapp and devices as trusted for local execution that would solve the problem. Even if one had to go to the IDE to do it.
Unfortunately, with with local smartapps coming through hub firmware updates that doesn’t seem likely to happen any time soon given their record at making changes.
Sigh. Guess I"m stuck in that limbo of unpredictable response times for the foreseeable future.
They say that they are working on this, specifically for the sorts of device types and apps you are referring to. Timeframe later this year (ya sure). But you are right, unless and until that happens, not much point in migrating.
It’s cool that Smart Lights can run locally, but most of my lighting automations are done with a custom app. So, I’m in the same boat.
i believe they intend to but…their track record on delivering on promises in a timely manner is less than ideal. I’ve been a customer for a year now and ST may be on its last few months here unless I can find a way to make it reliable. The unpredictable lag is just killing acceptance here.
ROTFLMAO. 
(Does anyone use that acronym anymore? Well… at least we have emoticons too). What’s the emoticon for “DHYB” (Don’t hold your breath)?
maybe?
Just thought I’d put this here so it would be easy to find later. 
This is the link where you can see exactly which smart apps are running locally on your hub.
At the present time it will be empty except for individual automations from the new smart light lighting wizard, provided those instances are using standard device types.
I have verified that you do get a listing for each individual instance. So if you have named one “guestroom lighting rule” and another one “sunset lighting rule” you will see two entries in the following table:
https://graph.api.smartthings.com/localInstalledSmartApp/list
Dude where did you find that? I’m all over the IDE and i’ve never seen that.
Support gave it to me.
Thanks for that link, I’m currently rebuilding my v2 and I’d like to decouple my smartapp functionality. I’ll install whitelisted functionality as the “critical” pieces with the “bonus” functionality broken out into smartapps that run in the cloud. I’m struggling to figure out what will run local before I setup everything. Is there an easy way to tell what apps and which devices are on the list? Forgive me if it’s out there, my wife usually has to help me find peanut butter in the pantry so not so good at searching these days.
I think it is too soon to design your system around local execution, as Hub V2 was released with minimal capability in this regard and will go through progressive iterations of improvement. If you avoided everything non-local now, you wouldn’t be left with much.
**In general:*f
If any SmartApp uses a non-official Device Type, it likely will not execute locally. Non-published SmartApps, never local. Obvious “cloud stuff” (e.g., Echo) not local.