Hubitat Elevation Hub - Home Automation that is local

Terry - genuinely curious…What new automations are capable of ruining locally aside from Smart Lighting and a bit of SHM?



@JDRoberts Gave a pretty accurate description of the current state of local execution. There is also a faq about it on the support section of our website. Not going to speak for Terry but my comments have been about what we are doing moving into the future.


Different thread, though. :wink:


Nothing - yet.

Announcements are expected at SDC.


And that’s how @jody.albritton gets in trouble and goes into hiding for another year. :slight_smile:


Accurate. :bomb:

But seriously. Haven’t really been hiding, just a lot that has happened in the last year has been behind the scenes. There will be a lot to talk about over the next few months. Right now it’s just hard to say anything because we have huge a amount of things in our pipeline. Some will ship before SDC, some will be announced there, some will come later. A lot has changed with our platform architecture and more will change in the future.

I think some of it will be of interest to folks who made the switch to Hubitat solely for local processing.


Long post ahead, but this is for anyone else thinking about switching from ST to Hubitat like me.

Coming from someone who was on ST for almost 2 years before switching to Hubitat for local control, let me just say I think I understand why smartthings has certain functionality offloaded to the cloud. …

I’ve tried possibly every single popular Home Automation system out there:

  1. Home Assistant - Not quite mature, pain to configure Zigbee/Z-Wave devices and many of my existing devices are unsupported or require too much work to set up.
  2. Homeseer - Rock solid Z-wave, but UX/UI leaves a lot to be desired and I’m not sure the company is aware that Zigbee devices exist.
  3. OpenHAB - I just didn’t care to keep playing with this one, HASS seemed better in almost every way.
  4. Zigbee/Zwave2MQTT and nodeRED- Good device support, but not quite turn key.
  5. Indigo - Mac only, who the hell wants to use a mac as an always on server?

And finally, Hubitat. I’ve been on Hubitat for almost 2 months now and here are the pros and cons:


  • Local control - Obviously this is what drew me to the platform. Instant on/off and reporting via the WebUI on all zigbee/z-wave stuff. No reliance on the internet for anything, no latency. Everyone probably knows this.
  • Privacy - your data is your data and all that.
  • The developers are very active on their community forums and new device support and features are added at a pretty rapid pace.
  • Integrated rule machine is pretty advanced and I ported almost all of my complex WC rules with a little bit of effort.
  • Hub backups are allowed, no forced firwmare updates either. If everything works good, feel free to just leave the thing in a corner.

Which leads me to cons… which is really just one big fat con…


  • Custom apps/drivers compete for resources with the core system. At least from MY understanding. The whole reason I went with Hubitat instead of rolling out my own DIY system on my overpowered x86 homelab is because I wanted a self contained system that could just be my “Home Automation” box. Which means I’d rather not admin Homeassistant, manage my automations on a docker instance running NodeRED, then manage another docker instance running whatever other bandage piece of software required to keep everything glued together… You get the idea.

  • Because of above - if you have a rogue app or driver, your ENTIRE system will slow down to a crawl. This means automations will have a 2-3 second delay. You walk into your bedroom and the lights turn on a few seconds later. Your SO is then making fun of you. WebUI interactions will have a painful 5-6 delay when doing anything. In some extreme cases, I’ve had the hub completely crash on me. (This was again caused by a smartapp) Note: My mesh is very stable, I have a good amount of repeaters placed in ideal locations.

  • Rogue apps or drivers can luckily be disabled easily - but in my experience this has not proven to be very useful. For instance, over the past 2 months, I have had maybe 6-8 custom smartapps. 2 of those were found out to be known problem makers after I did some research on the forums, so I disabled those. Everything was fine for a while, but now it’s back to the same slow issues. I neither have the time nor the patience for the trial and error required to figure out the root cause behind these issues. And even if I do, what’s the guarantee some other smartapp or an update won’t bork things?

  • I have now resorted to deleting every single custom smartapp, and just using the hub as a dumb box to just talk to Zigbee/Z-wave devices. This means that I now have to set up and maintain separate systems to do all the stuff I had previously accomplished using Hubitat smartapps.

I get that it’s impossible for Hubitat developers to ensure that all custom third party code is following best practices and not sending the hub into an endless math loop - but they really need to implement some method to isolate or “containerize” core hub processes from the custom smartapp side of things so that at the very LEAST core functionality remains intact! Custom groovy code shouldn’t crash silently crash your hub!

To sum up my long rant - would I recommend that you switch from ST to Hubitat?

It depends. If you’re the kind of person that likes to experiment with a lot of smartapps, I’d say no. If you just need a box with pretty solid device support and a good rule machine - I’d say it’s worth a try.


Your list is missing a few of the big ones… :wink:

Among the very popular:

Apple’s HomeKit

Among the popular for tech enthusiasts:

Every system has pluses and minuses. Choice is good. :wink:


The built in apps like Thermostat Manager, Simple Lighting, Mode Manager etc. don’t do what you want? You can do some useful stuff with just them.


I think it’s becoming more apparent every day tha groovy is not a great language for embedded systems. One of the many reasons we are going in a different direction for local processing.


Honestly, groovy works pretty darn good. The problems with CPU utilization on any system are going to lie in the firmware and how it utilizes system resources. If you’re not using the system correctly, or your hardware isn’t quite designed for your purposes then you’re going to run into problems, especially when you’re playing with java.

1 Like

more details at SDC?


That’s true about any system but groovy was not designed to run in an embedded scenario and does not have a lot of the protections inherent to some other languages that are.


So… about those limitations… 250 behaviors… which apps are affected by those? I understand that scenes and “new app” custom automations app are…

but what about user developed apps? Like webcore.

1 Like

Only the new automations implmented by the new app at the moment. Webcore is not impacted by the limit.


Like Lua, perhaps?

1 Like

Lua is one example of an embeeded scripting language that has some infrastructure in place that sandboxes the memory and CPU. We are using Rust as an another example here at ST.


© 2019 SmartThings, Inc. All Rights Reserved. Terms of Use | Privacy Policy

SmartThings; SmartApps®; Physical Graph; Hello, Home; and Hello, Smart Home are all trademarks of the SmartThings, Inc.