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.
(Does anyone use that acronym anymore? Well… at least we have emoticons too). What’s the emoticon for “DHYB” (Don’t hold your breath)?
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:
Dude where did you find that? I’m all over the IDE and i’ve never seen that.
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.
- 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.
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
I don’t know for sure if there’s a subset of the standard types (that don’t require Internet, obviously)…
Trial & Error here we come…
Comimg from v1, Smart Lights can be described as a suite of apps. They have merged several apps into one. Big Switch is there, so is Smart Nightlight. Power Allowence, just to name a few. The rule of thumb for local processing, as others mentioned, is to stay with officially published device types that are not conected cloud to cloud (e.g Hue bridge).
LUX level is pretty much my only gap at this point.
There are other headaches lingering around, but luminance is indeed the biggest omission.
Dang, using the link above, I now realize that my hello home actions are not even running locally. I have exterior Cree bulbs turn on at dusk, and that’s not showing. Blah.
So far I found Cree and Hue disqualify routines and apps for local processing, the z-wave switches I have and GE Link bulbs are OK. If you’re toggling the Cree bulb in the actual hello home routine and that’s all that is disqualifying it from local, you can remove the Cree bulb from there and then add it to the Smart Lighting as an automation that responds to mode change (assuming that also happens as part of your hello home action). If you’re ever offline that’s the only piece that won’t work.
Not doing a lot around local processing in its current state is good advice, but this little trick should be minimal.
Yeah I didn’t think about using the Smart Lighting app based on mode. Good call. Gosh I sure wish I could run my other stuff locally… like a custom door locking app I wrote.