SmartThings Community

Local Processing in Hub V2

( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #3
  1. 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).

  2. 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.

  3. 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.

1 Like
(Brice; #4

That is disappointing. Where was that announced? I must have missed it.

(Jason Mok) #5

In this post.

1 Like
( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #6

Confirmed in and with more detail during the Developer Conference call, by @hagins.

(Brice; #7

Bummer. I couldn’t make it tonight.

(Brice; #8

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?

(Mike Maxwell) #9

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.

( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #10

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.

1 Like
(Linda Thomas-Fowler) #11

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.

1 Like
(Bruce) #12

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.

1 Like
(Linda Thomas-Fowler) #13

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.

( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #14

ROTFLMAO. :laughing:

(Does anyone use that acronym anymore? Well… at least we have emoticons too). What’s the emoticon for “DHYB” (Don’t hold your breath)?

(Brice; #15

:no_entry_sign: :blush: maybe?

1 Like

Just thought I’d put this here so it would be easy to find later. :sunglasses:

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:

[RELEASE] Iris Smart Plug (3210-L) Zigbee Plug with Z-wave Repeater
(sidjohn1) #17

Dude where did you find that? I’m all over the IDE and i’ve never seen that.


Support gave it to me. :sunglasses:

(MT) #19

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.

( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #20

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

  • only use official SmartApps and stuff like Smart Home Monitor, Smart Lighting and Routines.
  • only use official “works with SmartThings Devices”

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.


For right now there is one and only one SmartApp that runs locally: the smart lighting one that is under “SmartThings recommends” in the marketplace. And only the standard device types.

1 Like
(MT) #22

Thanks for the clarification, I thought there was a subset of standard devices so this helps.

I’m certainly not automating a hotel around this primitive release of local exec, but I’ve come to accept that I’ll always be mucking around, so my design is certainly meant to change over time. I hope ST eventually has a running list so I can keep up with what’s local and update my setup as things change because let’s face it, reading through all these forums is HARD :smile: