@hbr, who knows… I have ST now and this is a new toy for now. Can’t wait to get it.
So what advantage does Hubitat have over Vera? Honest question because I’ve never used either.
@prjct92eh2, well that’s the big question so far. Hubitat is actually really new, like released 3 days ago and many of us just learned about it today. How it compares to Vera, I don’t know. Never used Vera.
Hubitat runs groovy, which means you may be able to port over some things you had written for SmartThings, but I don’t know details. (updated to note @tgauchat 's correction below)
It also sounds like hubitat will let you use custom device type handlers for zigbee devices, which vera does not. But I don’t know for sure.
There’s also an integration for Lutron, but I don’t know the details of it
@JDRoberts, bad news on the Lutron integration, well for me at least. It is for the Caseta PRO or RA2 systems currently. Won’t work with standard Caseta bridge.
However Home Assistant has a working Caseta integration. Their stuff is all in Python, so after I get the Hubitat I’m going to look into re-engineering their integration. Time to learn Groovy
I myself use the pro smartbridge anyway because I knew there would be other integrations I would want. But I appreciate the information, it would be good if they added that to their site.
@JDRoberts, in hind sight I should have bought the pro version. But it was grab and go when I was at Home Depot one night. I’m considering buying a pro bridge though.
Just because the SmartThings traditional DHs and SmartApps are written in Groovy code in the IDE doesn’t mean that they are portable.
SmartThings has a significant abstraction layer between the Groovy code and the various pre-compiled proprietary libraries, objects, definition blocks and abstractions, etc., etc. to make it all run in the SmartThings Cloud and Hub,
Perhaps Hubitat has reverse engineered the entire relevant and required parts of the SmartThings platform? That’s quite a feat and will be interesting to observe.
Rule Machine is running on Hubitat, with minimal changes per Bruce. Code portability is sounding promising.
including WebCore says one post
Good point, I have corrected my post above.
I’m in on this.
Local=better for all the all important human interface to the system. Latency and outage wise.
Works with ST so I don’t loose anything I’ve currently got.
Works with WebCoRE (hopefully not disabled at some point) so any conceivable interactions can be pulled off.
I still use Rule Machine for some very specific tasks that are just easier than CoRE. All local is the cherry on top.
I figure that between Rule Machine and local device drivers, I can get 90+% of my system on Hubitat. The other bits either stay in ST completely, video stuff, phone app. Other unsupported stuff via the connector, Insteon, Harmony. Or a combination.
The most critical thing is my stance on home automation. The automation part. Without that, why do any of this? This system is built, as Bruce said on their forum, FOR automation. That has to be local.
I’m “IN” as well. I have long desired true local processing - for performance, reliability, and privacy. The team of people behind this are some of the best ST Community Developers of all time. For $99, I am willing to take a chance on it, just like I took a chance on ST many years ago. I also feel like it is a way of paying back those who helped make the ST community what it is today - a thriving group of people willing to give freely of their time and talent to accomplish some amazing things.
I just wish that the SmartThings leadership understood the value of the ST Community and encouraged it like they once did back when SmartThings was young, nimble, and not owned by a mega-corporation. These days, ST seems to have somewhat forgotten their roots, and have not only failed to deliver on many promises (local processing, migration utility, accessibility features, etc…), but have actually somewhat closed off the system to private developers (no more developer meetings, no community liaison, no more submissions of code for publication, no road-map, etc…) “Amazing things” & “Platform Stability” have been long promised, and used as an excuse for cutting off community developer ties, but neither have been achieved to my satisfaction.
If Hubitat can recapture some of that grass-roots enthusiasm and excitement for an open platform, and resolve some of the long-standing functionality requests (e.g. backup and restore, local processing, web-ui for configuration, and maybe even entry/exit delays!) then I am all in. Maybe getting “in” early will also help set some direction for the product moving forward, as a true community supported platform.
For $99, I say it is worth a shot! Bruce has mentioned that he has installed the system at multiple locations where it has been running for many months without any failures. The focus is on true home automation, which I feel requires robust local processing to accomplish. This is something I have been reluctant to attempt with ST due to the Internet and Cloud Server dependencies. With a family of five, I do not want to get calls while I am away from home to explain why things don’t work when or how they should.
I believe I will be a combination SmartThings/Hubitat user for quite some time as both systems have their Pros and Cons. It has even been mentioned in the Hubitat forums that they have tied the two systems together. This may be a way of taking advantage of the best of both worlds.
Fun times ahead, for sure! As others have mentioned, having a new toy to play with is always fun!
Fun new toys… yes indeed!
I’m sure I’m not alone when I mention that one of the largest “environmental conditions” for many of us to navigate (yes, you already know what I’m about to mention!! lol) is WAF.
My home’s working pretty well now. Wife has bought in, because almost everything “just works” now. She can say “Alexa, turn the salt lamp 40%” and the thing turns on at 40% brightness. She can fill the hot tub, and the sensor will alert her when the water is at the right level. At 10pm, my android control tablet announces whether any windows/doors remain open - and lets us know in which rooms.
I will be slightly reluctant to start messing with that.
Especially since many of the associated systems (Hue, Ecobee, Chamberlain, others) are cloud-dependent.
That said… if this new system can interact with all those others in the usual fashion while providing more local control - such as allowing ethayer’s Lock Manager to run locally** - then I would certainly consider making a move.
**Imagine not needing to be connected to the Web for my codes to load to, and unload from, the front door lock on schedule! That would certainly be terrific, a great security enhancement.
I’ve just had some really bad news…
They don’t currently produce an EU/UK version!
Not sure when (if ever) this will happen
I totally understand where you’re coming from and appreciate your reluctance to just jump in. I am jumping in with eyes wide open, and expect some bumps along the way. To be honest, the challenge is part of what attracts me. In the short term, critical integrations and automations will stay in the ST system until I know the reliability and usability of the new Hubitat platform. For me, HA is more of a hobby than a necessity. Everyone’s use case is somewhat unique.
Once thing to point out - the Hue lighting integration with Hubitat is local, I believe. No cloud service required. The devs really seem to want as much local processing wherever possible. Patrick Stuart even has video posted showing a remote-to-hubitat-to-hue lights integration, where he touts to near instant control.
My garage doors are controlled by a custom Arduino platform that my son and I developed. Unfortunately, ST has never allowed custom Device Type Handlers to run locally on the v2 hub, even though this was touted as a future feature. For me, moving to Hubitat should improve my reliability and performance.
This may be a stupid question, but if you have wifi enabled things (hue, ecobee, chamberlain, others) wouldn’t you still be able to control them without internet as long as they are all still connected to the same network and everything was local? For instance, if the Hubitat was connected to your wifi so that it connected with these things, but all the HA was ran locally?
That’s not a stupid question… Some integrations can ONLY be accomplished by communicating with the vendor’s cloud service. Many devices do not provide for local LAN communications. I believe the Philips Hue bridge does allow for LAN connectivity. I am not sure about Ecobee, but I believe Chamberlain is only via the cloud, and that is somewhat of a hack to make it work with ST, IIRC.
According to posts in the hubitat community. Every custom app and every custom DTH (driver as they call it) runs locally and privately.
Running locally doesn’t mean an Internet connection is never required, however, if it is to a third-party integration. So either they don’t have those third-party integrations or the local driver would still have to connect to the foreign cloud for that particular integration to work.
For example, there is no way at all to have Amazon echo only run locally. You have to be able to reach the Amazon cloud. Same with IFTTT, even if you are just using the webhooks channel.
As others have mentioned, Phillips does allow you to reach the hue bridge strictly via your local LAN, you don’t need Internet. Logitech Harmony is the same. But, again as was mentioned, chamberlain does require that you go through their cloud.
It’s up to each individual manufacturer whether they require third-party integration is to go through their!cloud or not.
For the past 10 years there have been several Home automations systems which ran their own operations locally but still use the Internet for email or webhook connections.
That’s another reason why it would be nice to see a table of supported devices which showed you which ones connected directly, which was connected via LAN, and which ones require the Internet in order to reach a third-party cloud.