Local Execution and Reliability

We have spoken publicly about moving more processing to the edge (hub). There have been two+ years of under the hood changes for moving towards this new future. If you want to experience running the groovy sandbox on local hardware, you can demo it with Hubitat. Way back when hub v1 launched the only way to make a hub for that price was cloud processing. There is a massive set of infrastructure behind the old datamanagement platform.


Feel free to ping me if you have any questions. :smiley:


I’m very surprised. That means the voice recognition is, at least partly, done on-device. I assumed it was always cloud-based.

All the devices do onboard voice recognition for the wake word. The question is how much farther can they go?

Amazon gives you a few options. It’s not natural language the way the cloud-based service is, but it works OK for “Turn on the entry.” :sunglasses::bulb:

1 Like

I think the reply from Jody of SmartThings is a source. It was a big theme at SDC 2019 and the new Rules API from recollection. It may have been also talked about in this good talk by Adrian (I jumped to a good part about volume, and this is just webCoRE, but the whole talk was good).

I think this talk was where I got my webCoRE script to check battery status on devices. Love that piston!

Something I certainly would recommend for those who are growing tired of large corporations running cloud-dependent, datamining infrastructure.


I have no doubt that Samsung can afford a better infrastructure than most individuals. However, in the real world what we want is a system that is responsive and reliable. Fancy specs don’t matter if you can’t use it or it isn’t faster than a local hub.

In your experience does Hubitat work at least as well as ST? Any pros and cons you can share?

1 Like

Funny … Didn’t experience any outage on my hubitat… Not to mention everything is running super fast on that “cheap” hardware


WebCoRE was crashing the Hubitat hub, now they are saying to turn off webCoRE logging because the hub can’t handle it, they need to double the CPU, memory etc If they improved the Hubitat hardware, in the future I think it would be a viable proposition.

It wasn’t a joke. I have SmartThings all over my house outages impact me too, but there are no perfect systems. I was addressing the commenters who asked why we don’t just let all the groovy run locally on the hub. There is plenty of evidence on Reddit and Hubitat’s own community that you can criple the hub with an errant rule or bit of code. In most cases a cloud envrionment scales out to handle that kind of thing. And for the hubitat lurkers, I wasn’t taking a shot at hubitat. It was a point of contrast. You can in fact test it for yourself. Hubitat isn’t the only local hub either. There is home assistant, openHab, homeseer, ISY, etc.


I don’t know a single person that uses webcore on HE… It’s not needed… Anyway… I am done and will stop derailing this thread

There are pros and cons with every platform… I still use ST for about a dozen devices (Arlo cameras, Ring doorbells) which is why I still lurk here from time to time.

I’ll start with Hubitat’s drawbacks… First, there’s no mobile app like ST has… I missed that when I transitioned but have eventually become used to it. Hubitat does have an app for Geo-presence and displaying the dashboard, but it’s not all that useful IMO. The platform also doesn’t have a lot of native, official integrations like Arlo and Ring. The community has more or less solved the big ones, but it’s a drawback for users who don’t know how to install code.

For the positives… There’s no cloud or even internet dependence, beyond any specific integrations that require internet. For example, back in November a semi-truck took down my FiOS fiber drop for about 5 hours. The impact wasn’t even noticed. All of my motion lighting worked, security worked, and I could even disarm the alarm if I needed to. Point is, I was never locked out of the system. And finally, the platform API opens up a lot of opportunities for integrations not possible on SmartThings… Things like eventsockets, websockets, local http calls, local oAuth endpoints open up a ton of options. There’s a Ubiquiti UniFi integration, MQTT bridge, Automatic Pro integration with live-streamed location, Node Red, and many others that the closed ecosystem here prevents.

The porting of Webcore to Hubitat required more work than a simple port to prevent runaway apps… Hubitat, unlike SmartThings, does not enforce resource limitations on execution time or number of events over a period of time. The trade-off is people here complain about the “guard rails”, while folks complain about Hubitat hubs that are resource-bound. No matter how you look at it, there are limits to both systems.

And if you do need more processing power, you have options… Buy a second hub mesh them together using HubLink/Link to Hub, Other Hub, or of course, HubConnect. Some folks have done that and dedicated a hub just to WebCore and rules handling, or to extend their SmartHome into a detached garage or workshop, or office… A few even have mobile hubs in RV’s all tied into one unified smart home system.

Groovy probably isn’t the best choice for a smart home hub, but I think the real reason why this doesn’t happen is because the SmartThings hubs are too underpowered with key specs like memory and CPU that were cut significantly with the v3 hub. Not that’s a problem for SmartThings or Samsung, it better aligns with the business model…


I think that’s one of the things that SharpTools is used for.

I would imagine so! Since I haven’t used it for anything substantive I don’t know the limitations. I do use Ring, Hue etc.

I have a Ubiquiti, AmpliFi system myself. Not impressed so far, but that’s another story. What kind of integration even exists for such a platform?

Of course the lack of need for internet is a big selling point for a locally based “cloud”. If the hardware and functionality doesn’t exist though, it may not be the best solution.

Have you used HomeAssistant/HASS.io? That is Pi-powered so is certainly oomphy compared to the dedicated hardware. It’s also got a huge user base and is completely open source. I would imagine that if you considered all the community generated code it is pretty broad, but again, I haven’t really done anything with it except install it and plug in a Z-Wave/Zigbee adaptor.

That’s fair. The point I was making was that local execution alone is not a panacea Local execution will also not prevent updates from breaking your thing that works today when something new is introduced to the system, specifically when you are allowing the execution of arbitrary code. With some of the other hubs I mentioned it is a lot more obvious when something consumes all of the avaiable resources and it grinds to a halt. There are many instances where this happens on our platform and we scale out to meet the resource demand with end users never noticing. Again, this was not a defense of any platform outage or saying one way is better than the other. I answered the question of “why not just run everything locally, that would solve all these problems”.


Also with many, although not all, local execution hubs you can roll back to a previous checkpoint where things did work while you figure out what went wrong.

And again with most local execution hubs, although not all, the customer decides when new code will be introduced, and can either deny or defer updates until they are ready for them.

Put those two things together, and you generally get a lot more day-to-day stability just because nothing changes until you’re ready to have it change. :sunglasses:

But I agree, both architectures have pluses and minuses, it’s just a matter of finding a system that best aligns with your own priorities and preferences.


Split the discussion about local execution into its own thread to de-noise the thread about the outage.


So glad I left and moved on to local execution that works.

1 Like

So where did we land on this? I have some Enerwave Ceiling Mounted Motion Sensors and I see they have their own device handler that executes in the cloud. If I make the device handler a “SmartSense Motion Sensor” it will execute locally. So, should I try to run locally? Not care? The bottom line on this conversation is unclear to me.

Also, the SmartSense list of handlers: are these all the new ST handlers that are the best ones to use when able?

Since smartthings never gives you an entirely local operation (for example the app and notifications always require the cloud), it’s more about assessing each individual use case. There are two different use case categories to be concerned with.

One) everyday operations when the cloud is available as expected. For this situation, you probably don’t really have to worry about local versus cloud as long as you are satisfied with the QOS (quality of service) of your existing set up. If you do have some sensors or some switches that seem to take a long time between physical event and expected outcome, you might want to see if some of those can be moved to more local operations.

Two) planning for outages. There will inevitably be sometimes when the smartthings cloud is not available or the Internet is out. What, if anything, do you expect to still work from your smartthings set up then? We have an FAQ that discusses this in detail, but topline I think the most important issues are three-way light switches, light switches that control smart bulbs, Motion sensors that trigger lights, and security sensors that trigger a local siren. These are all things that you may specifically want to have continue to operate even if the Internet is out. Use cases where a physical event in the environment, like someone walking into a room or physically flipping a switch causes something else physical to happen in the environment, most typically a light coming on, but may be a siren.

Notice that none of these are use cases where the trigger is voice control or an app or even a schedule.

For these kind of physical event triggers, I think it generally is useful to move them to local operations so that they will continue to operate as expected even if the Internet went out.

Again, see the FAQ:

How to: Planning for Outages


Thank you so much @JDRoberts!

1 Like