Well, hub "locked up" again today... I haven't added ANY apps or user drivers in a while - weeks...
Everything was fine this morning. Then mid-afternoon I noticed my lighting automations weren't working. I was able to get into the hub, but it took ~5 minutes to login to the web interface - so clearly something was gumming up the works.... Zigbee radio also said it was offline when I logged in. As usual, nothing interesting at all in the logs. No repeating errors, no massive amounts of things logging, etc...
Hub rebooted successfully once i got into the web interface, so that's a plus.
After reboot I see that zwave devices were coming in just fine based on the events - but the automations were not happening.
Same situation with me.
I raised another ticket 2 days ago.
No response I'm afraid.
They are either very busy or have no answer to it.
The frustrating thing everything was fine until 2.0.9.
I cannot revert back to 2.0.8 as there has been 2 hot fixes so no earlier file is available.
Also I'm on holiday so I have to check everything 4 times a day!!!
Well, I think the issue is that Hubitat's stance is that "the hub doesn't lock up without user code, so it's on you to troubleshoot/figure it out".
I get that, but when a hub that runs fine for weeks/month on end randomly slows down/crashes with the zigbee radio saying it is "offline", not sure what we are supposed to do?
In my case there were no errors being generated in the log, no abnormal traffic, and no changes to the hub had been made (I was out of town all week, so I'm 100% sure it wasn't being tinkered with).
So what am I supposed to do? Remove all user app/drivers and wait weeks or months to see if it does it again? Well, that's not reasonable to me.
I'm going to go back to the drawing board and start looking at other solutions again.
Maybe I need Hubitat PLUS something else that doesn't crash/lockup for my critical items (pool controls and thermostats). Or maybe just something else and no Hubitat. We'll see.
My hub (running 2.08.113 non-stop since I applied it on April 9th with literally no changes being made to its applications since) stopped running automations sometime last night. It still responded to ping but I only had patience enough to wait for several minutes on the unresponsive web UI before pulling the power and restarting it. Came right back functioning normally with nothing unusual in the logs.
I'm grateful this didn't happen when I was out of town last month; I'd feel more comfortable with a scheduled reboot option to mitigate what I assume is some kind of a resource exhaustion issue.
Without any better troubleshooting tools, system statistics, or logging I don't see how this is ever going to get resolved.
Really bums me out, as I really like the community and the idea/promise of the platform. But as of yesterday Hubitat had to be downgraded to 'non-essential' service in my house.
node-red is showing something. Here is my hub response time up until round 6PM yesterday when I power cycled. Not sure what it means yet but seems clear there is a shift in response time.
Submit a ticket I guess, and hope support engages. If the hub is doing something scheduled at 2am, only they will know.... Thus far they have commented almost zero on these topics, though.
The hub backs up the database at 2am. That's been discussed before. They've never dinied that it could have a performance impact for some uses when it happens. However, I'm no longer seeing that with the current platform 2.0.9.133.
But I am getting weird slowdowns at odd times of the day that didn't previously occur. The discussion about the hub hitting the NTP time server so often is intriguing, but I have no way to test if that will improve things. The next platform build is just days away. These guys are pushing to give us cool capabilities and improvements. I don't expect to be let down, but I also don't expect to not have any bumps in the road.
I have custom code installed. If I start disabling (which, except for Homebridge, I have not done yet), then I might find a connection between the custom code and the slow downs. So, at this point, it is still on me. I'm a tinkerer. I'm going to break stuff on my own.
My hub lockup yesterday definitely happened outside of the maintenance window... Worked fine 1st half of day, died sometime in the afternoon. No one has logged into or looked at the hub for 8 hours+ before it crapped out.
I'm a bit of a tinkerer too.
After RM 3 release I redid all my rules to rationalise them. This cut out quite a few rules but it did make them more complex.
This coincided with my hub grinding to a halt every few days.
The first ticket I raised they assured me this was pure coincidence.
No response to my ticket of 2 days ago yet.
So I'll throw it on there. I have noticed my hub locks up periodically as well if not rebooted. Usually 5 or 6 days or so I have not put in a ticket as I have lots of custom code.
I have also noticed that if the room the hub is in heats up for whatever reason I am more likely to get a lockup.
And the custom code you're running? Have you tried just disabling one of them to see what happens? If that doesn't do it, move onto the next until you find (or don't find) a change. The tool to disable them really does make troubleshooting easier.
Nope. The exact same code and drivers have been running on the hub for months with no lockups.
So what am I going to do, disable everything and then wait WEEKS/MONTHS to see if it locks up again? Not likely.
If the lockups were repeatable, or triggerable, disabling en masse or one by one would be a fine answer. But when the lockup frequency is random/weeks apart, disabling and waiting simply is not going to work.
