The hub issues do seem to happen more the more devices there are and the more user code there is. Which sounds like memory leaks or resource exhaustion.
We will never know, though, as Hubitat doesn't expose any meaningful loading statistics.
I will say that if it is resource exhaustion, I would have much rather paid $300 for one high powered hub with more resources than the $300 I paid for 3 separate hubs...
That said, my 3 hub system is setup and working. So it can be done (although not without some good planning and work). Previously simple things like dashboards take a lot more thought - a dashboard can only connect to one hub....
I actually didn't find that to be true. I only replicate a small subset of my devices. But I concede that is very dependent on how you are doing logic/RM rules/notifications.
No argument there. But a solution like Home Assistant has MANY tweakable/configurable individual internal components (and many of then NEED to be tweaked to make things work right). Not sure I would call it less complicated, even thought it is in 'one box'. It seems like I'm constantly having to fiddle with both YAML and internal component versions on my Home Assistant setup.
Anyway, good luck either way. In the end the right solution is the one that works for YOU.
I will say that if I get to the point that I can't avoid hub lockups, Home Assistant is what I would likely switch to. Either that, or I would rip out the zigbee devices I have and go back to HomeSeer (already own the license, so cost isn't a barrier). Not sure, and hope I don't have to make that decision in the end.
Indeed. I'd expect roughly no support at all. But I would have access to all the gubbins, and I could then potentially fix the problem myself. Not attractive, I'll entirely agree with you, and it's not like I'm claiming that there's a sunny upland anywhere else in particular, but what's entirely clear from today is that a device that can lock twice in a day isn't something that can continue to be working here. We'll be back to manual light switches and 'why did you spend all that cash on something that doesn't work' conversations, and life's REALLY too short for that.
Anyway... we'll see if support can cough something up that will help. They've been good with other people in the past, but hubs that aren't stable (for at least those people who have them) looks to be a pain point that's not going away, for me at least, and by the look of the number of threads, some other people too. Equally, I appreciate that the team isn't huge, and can't fix everybody. Sadly.... the ultimate result of 'can't fix everybody' is also 'can't retain everybody'.
Maybe I'll check back in a couple of years... I'm sure eventually things will be resolved, or a version hub will be available by then, and will have more available resources and be less fragile.
Yeah. I'm with you on a 'pro' hub. In a realtively real sense, by moving from a hub based solution to something that I can host on a proper platform, I'm trying to simply remove available resources from the pool of problems. But the Hubitat platform won't (not surprisingly) let me move off their hardware, and they don't make a bigger one. Moving off the hub also gets me something massively more fault-tolerant to run the automation on, and that's a comfort too.
it really seems that both you and Jason have a very realistic view of the situation. As a growing company, they need to have a growing user base. Making a "Pro" hub so early in their existence would satisfy a few, and overlook the needs of many. Not an approach I would take either if I were building the brand, writing the code and supporting the product.
The idea of the "Pro" crowd purchasing multiple "Consumer" level hubs and connecting them seems like a very logical decision. Ultimately has far more potential to satisfy the needs of both camps. I'd argue that @JasonJoel 's approach actually has fewer moving parts than Home Assistant as well.
I was in the same boat as you were. I wanted to have a Grafana dashboard with an influxDB, I wanted to have homebridge running as that is what my wife is used to and use my Echo to let my house talk to me. The only thing I don't do is Chromecast, which is also known to have issues. I was dealing with daily reboots myself and can happily say that I am without now for at least a month and a half!
here is what I did:
InfluxDB logging: instead of using the on-system Influx app, I deployed a Node-Red instance that listens to the eventsocket and pushes the events to an InfluxDB. You can find more information here:
Homebridge: I was also using original on-system Homebridge app. I completely rewrote the homebridge plugin to use the MakerAPI. You can find more information here:
For my Echo, I use Alexa TTS Manager written by @ogiewon. More information here:
Lately, I started to deploy a multi-hub strategy, which has shown to run very reliable. I use HubConnect to link them together. I have one hub with radios enabled (Zwave and Zigbee) and one hub with LAN devices and custom code. I am currently in the process of splitting up my zwave and zigbee hubs into two hubs though. You can find more about HubConnect here:
I don't think this step is needed but my desire to tinker makes me buy more and more hubs......
Please keep in mind, devices can also havoc your system. I had one particular Osram bulb that was defective and spammed the entire Zigbee stack to a grinding halt
Curiously... the one problem I'm pretty sure I HAVEN'T got is a zigbee/z-wave related problem, unless it's sole symptom is a hub that stops doing anything at all on a regular basis
I'm possibly in a slightly unusual position in that while I've got a lot of devices, well over half of them are just hue lights, and they're all looked after by three separate hue bridges (yes... I appreciate the irony of complaining, and then wanting only a single hubitat hub), but to be honest, I got the hubitat in the FIRST place as it was one of the few offerings that had documented support for multiple hue bridges.
So... z-wave fairly stable... zigbee barely used.. .and stable. Hub... really not stable. And because I can't diagnose what's MAKING it not be stable, I can't fix it, or even know what I should move around to help.
That's the bit that's ultimately eroding my confidence in the platform.
I've now removed all chromecast devices, removed the integration along with anything else that doesn't seem to be "Required" for actual use of the hub in my environment. Unfortunate because the announcements via TTS on the home mini's was one of my wife's most liked features.
I share this frustration. While I really like the Hubitat gang and appreciate what they've accomplished in <18 months, I haven't changed my opinion that they simply have not done enough to help us in this area.
There just has to be a better way than 'turn it off all your stuff and see what happens'. In my case my lockups were WEEKS apart - I'm not going to turn all user space items off for weeks and "hope" it helps.
You can go with VLC Thing for announcements until the Chromecast Integration is stabilized. It's what I was running before and it worked just fine with my mini.
I don't recall seeing this suggestion. I do recall the suggestion to disable one thing at a time. I know in your case it will take weeks, but aren't you at that mark anyway?
And put another custom that support tells me to remove (EDIT: @SmartHomePrimer correctly notes that remove is the wrong here, I should have said disable) on the system?
Read some sarcasm in there but one thing we lose sight of is that the system obviously allows for customs but the assumption that they are well formed and handling errors/functionality just how the team would do it is something we as users have to really carefully weigh since there really aren't any safeguards to customs running away with the health of the system...
Very simple driver. No problems attributed to it. It gives warnings in the log when the connection to the cast device times out in 5 minutes, but doesn't case a problem. VLC Player runs on another system.
Yes, I see the irony in that. For me, it was trust that HubConnect is/or can be made reliable, or get rid of Hubitat altogether. I decided to try the HubConnect route first.
But trust me, the wackiness of using user code to work around (supposed) user code issues hasn't escaped me...
Seeing this statement made far too much. Support knows you can simply disable drivers and apps to troubleshoot issues. That's the whole reason the tool was developed. Support isn't telling anyone to remove custom code from the system to troubleshoot. Simply disable it.
You're correct, Support has no reason to ask you to remove something, and probably doesn't, but does ask you to not use it.
That said for me, and most of my stuff, removing is functionally identical to not using it since the idea of re-configuring isn't usually a big deal. The pain comes from not being able to use it, not having to remove / re-add it.
I haven't had a lockup since March 29th. Haven't done all that much tinkering though. No influxdb. I'm running Chromecast and HubDuino. 99% of my rules are still 2.5, so maybe there's something in 3.0 causing issues?
OK. So... the sum total of all of the effort dedicated to looking at the lockup - 'we've determined it might be caused by custom code'.
Well thanks, guys. I've done nothing but strip functionality out of the house by disabling said custom code. I'm afraid that there's nothing more I can practically disable and still have the place function, so that's as good as saying 'we're not the product for you at the current time'.
Guys - it's been fun, I learned a lot tinkering with it all, and I genuinely wish Hubitat and all the community here the very best experience from here on out. For what it's worth, I think the guys have the right goals in mind... but it's a tough nut to crack, and they're not charging very much for the hubs, which means that they probably can't afford to spend a lot on trying to support the early adopters.
Sadly, though.... this means that I might have been an early adopter, but I'm going to cut my losses, and look further afield.
I really think this same response is going to happen more and more if Hubitat doesn't give better tools for end users to troubleshoot where issues are coming from...
Hubitat will never be able to support every app/driver in-box. And while they can't be expected to directly troubleshoot user code for us, I HAVE to believe there are better metrics/tools/visibility they can provide us (above the easy disable button) to help figure out these issues on our own.
So I've said this before, but apparently it bears repeating. If you disabled something and your hub still crashed, why did you leave it disabled? I would have enabled whatever it was you disabled and then disabled something else. Correct me if I'm wrong, but it sounds like you just kept disabling more and more custom code but never found your issue. That would imply to me that the code you did disable was not your problem but something else you left enabled is.
For me, it was trust that HubConnect is/or can be made reliable, or get rid of Hubitat altogether. I decided to try the HubConnect route first.
