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.
Well... there's a couple of reasons for that, not all as sensible as each other:
If it IS resource exhaustion, then it's not that any particular piece of code is wrong, it's that the total required resources for all of the default code, plus the custom code, plus working heap, etc, is too high.
The general requirement for support to engage appears to be 'no custom code'. I've successfully made it as far as 'no custom apps', because they at least can be disabled without disrupting config.
All that's left is drivers, and that's disruptive to deal with in a diagnostic setting. Anyway... I'm out of grace period with which to investigate this, so I've started moving to another approach. All of the Hue's, Harmony, and HEOS devices have moved over without incident so far, and I've just started proving that I can move the z-wave devices without too much trouble. We'll see how I get on.
Oh... and a freebie bug report for you, Chuck. Detach the z-wave stick from the hub... and the system message that comes up informs me that ZigBee isn't working. Think you got that the wrong way around
Actually... it's reporting the Zigbee radio is down properly, and not saying anything about z-wave. That's more than just picking the wrong string - not sure why that would happen. Anyway... probably not important. You can probably safely ignore that bug report - unplugging the z-wave stick isn't really something you're supposed to do in normal operation I suspect
Not to derail the topic here but how does support diagnose a problem like this? Are they able to log into hubs remotely? Do they have a black bag of diagnostics tools they can run on hubs? If they don't allow any reasonable diagnostics tools for the user that puts all the load on them if they indeed have the means to view logs we cannot. Its not like seeing diagnostics such as CPU and memory load would have a negative impact.
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.
