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
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)…
1 Like
Trial & Error here we come…
1 Like
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).
2 Likes
LUX level is pretty much my only gap at this point.
There are other headaches lingering around, but luminance is indeed the biggest omission.
1 Like
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.
I just wanted to chime in that I have 90 or so child Apps on the Smart Lighting app and it’s really nice. It really is a monstrous performance improvement. Great Job 
1 Like
Now we know who’s bringing down the servers for the rest of us! And I was feeling bad for my 30s…I agree huge, huge improvement, nicely done! But there is room for even better (hint, hint…lights on motion fix). At the rate that fixes have been pushed since launch, we will have a platform that is closer to perfection in no time! (aka few weeks).
Except that, at the rate they are breaking things, we will have no system at all in the same timeframe!! It’s always been like this: they fix one thing and break two other things, and on it goes…
2 Likes
Oh no, I have been pleasantly surprised lately on the progress made. And it seems to me, like the rate of breaking stuff has significantly decreased in recent weeks. But such statement coming from you is indeed worrysome.
They stripped out 90% of the apps that were in V1, leaving people up a creek. Smart Lights has been broken from the day it launched, and is still broken. SHM is broken, so people have sirens going off randomly. Yesterday saw live logging broken, and many events just dropped on the floor. Mode changes are still flaky. Multiple users is broken. The list goes on and on.
I’m fairly sensitive to these issues, I can see them in failed automations that fail for no apparent reason. Yesterday, people were having huge problems, and all @twack had to say was, “it will be back to normal soon”. These things are never ending, in my experience, and there is always a friendly ST person coming on these forums saying “soon”, “code complete”, “the fix was held up by QA”, etc. etc. This is a pattern of behavior that has been constant with ST. They are certainly optimistic, and they always screw things up.
I wish it was a story of constant improvement, and I guess in some ways it is. But it is also a story of constant failure and disappointment. Just when I think things have improved, they break something essential that wasn’t a problem before, but now is. The impression is left that they have very poor internal software engineering discipline, or have created such a ball of string that it’s a daily miracle that it works. I don’t vent like this very often, but it is what it is.
7 Likes
Live logging is still broken today!!
I have to agree with @bravenel. A year ago my major issue was lag. Fixes were promised, delivered, found to be lacking and this went on for months. Things finally stabilized and the v2 hub was promised to provide local processing but as it turned out only in such limited circumstances that it was useless for me (half of my devices are run by home grown device types). I am unable to predict when or if that will change. Yes, they have promised to open that up but there are lots of other unfulfilled promises over the last year (native ipad app, native myq support, no bonjour support).
The two things that finally hit my breaking point was an inability to add in two hue bulbs and a failure for Things Quiet Down to fire more than once per day.
Instead, I bought a copy of Indigo for my Mac and a couple of fibaro z-wave motion sensors to replace my SmartThings zigbee motion sensors. My lights (mostly hue with a couple of z-wave switches) now turn on as soon as the motion sensor triggers. The ST “Smart Light” app lags behind by at least a second.
The customer-built hue integration for Indigo runs circles around ST’s integration. There was a customer built ad2usb integration for Vista alarm panels that works great and the z-wave part of Indigo has worked solidly for the past week that I’ve been running it.
Indigo lacks any built-in presence detection and the customer-supplied integrations have not been great for me but Indigo never made the claim that it could do it so I knew what I was walking in to. It’s probably the weakest link for Indigo right now. Indigo isn’t as broad in it’s coverage as ST but, so far, for my purposes, it seems to be working better. It’s not as simple to get up and running as ST but it’s easier to debug.
I’m not trying to bash ST. I really would love to see them succeed. Indigo is a small niche company (2 people) so could disappear in literally two heartbeats but overall it has been more reliable than ST for me. Granted it has only been a week and I’ve got a year of built up ST frustration.
I’ve still got ST running as most of my sensors were zigbee and Indigo doesn’t support zigbee but unless there is a major change with ST I expect that those zigbee sensors will eventually be replaced.
I think ST’s biggest mistake was their cloud model. All processing needs to be local. It can be managed from the cloud but the decisions need to happen locally.
Enough venting.
4 Likes
This was the proposed and publicly discussed plan for Hub V2, with the only exception being SmartApps & Device Handlers (in any combination) that explicitly required connectivity to another Cloud Service (e.g., Nest, since Nest currently only has a Cloud API open to us, Amazon Echo, etc.).
We even discussed what would happen if there was insufficient memory in the Hub V2… Could it page out to local storage (USB drives, etc.)? Sure… “under consideration”.
At worst it was to keep the most recently used Device Handlers and SmartApps local and flush out old ones when out of memory, and fetch them from the Cloud again when needed (like a web browser cache analogy).
Well… despite the months of delay and attempts to develop the platform described, they couldn’t get this dynamic model to work reliably. Furthermore, it was too late to put more RAM into the hardware design.
The result is (until they do a major redesign!):
-
the set of local Device Handlers and SmartApps are limited by RAM and thus are carefully selected by SmartThings operations.
-
the Hub V2 code is not modular and is packaged and delivered as a single firmware image. This means even the smallest change to a single Device or SmartApp triggers a full QA test of the Hub firmware and a full push of that firmware. Problems are not properly modularized and isolated.
Converting from Cloud to Hybrid architecture was expected to be a challenge. SmartThings was forced by deadlines to make a major, major, compromise from the intended architecture.
3 Likes
And that’s why it will be at least until the v3 hub until they can begin to address the fundamental problems in their architecture. Except they led us to believe that was what the v2 hub was going to do.
It’s a shame because this community is full of enthusiastic, wonderful people. But, the cloud platform is fundamentally the wrong architecture.
Now if they had sold the current package as ST Lite and a mac/pc-based add-on where the hub acted as a zwave/zigbee to lan converter to replace the cloud then they could have had a great system. Local processing for those that needed it and the current model for those that wanted to get their feet wet without needing to dedicate a computer to it.
2 Likes
-
SmartThings never intends to offer any product that fully “replaces the cloud”. There are far too many benefits to the Cloud that it is the foundation of their business strategy. SmartThings, in fact, has even publicly stated that they may someday sell no hardware at all. The “hub” could be built into various Samsung appliances (TVs, etc.).
-
I doubt the biggest problem with conversion to the hybrid architecture is the hardware processing / RAM constraint; it is in revamping the entire software stack of the Platform. So running on a custom hardware hub should actually be easier than running on a generic PC or Mac. The problem with a redesign at this point is how to maintain backwards compatibility? SmartThings couldn’t even deliver simple migration of back-end data from one Hub record to the new Hub record.
2 Likes