Add me to the list of people who had a hub freeze. And of course it happened when I was out of town.
In my case, connections to port 80 wouldn't work, neither would connections to 8081. No automations were working (time based lights were off when should have been on, motion lights wouldn't work).
Had to physically pull the plug. Then it came back working fine.
Looking in the log after reboot, everything was normal, then all events/logs just stopped. Nothing else until the reboot.
With no breadcrumbs or clues to what happened I don't see any point in submitting a support request. Just add me to the list of people this has happened to, and my frustration that the platform can't be relied upon to the level I think it should be...
Support have access to internal logs which MAY point you in the right direction to diagnose the lockup.
(They are extremely hard to read sometimes and don’t always show what happened)
It may be a custom driver or app running away and consuming all the hub resources.
Sometimes the logs show lots of errors for a particular app or device which may be a cause, sometimes they don’t.
If yours do, at that point, at least you have a starting point.
Also, it’s very useful to support if 20 different people report issues and they all turn out to have errors in the logs relating to a particular app or device driver.
That way, support have the option to work with the author to try and fix the problem.
This happened to me a couple days ago with Hub 1, around 4:47am when my meshes are largely low traffic. The only symptom I saw was a little sluggishness with automations right before bed. Two days later my coordinator hub locked up while I was saving an app. It too was runnign sluggish moments beforehand...'
I am starting to think the hub slowdowns may be a symptom of an impending crash.
I'm in the club too, got my main hub locked a couple of days ago, no error logs, a little slow before it died, reboot resolved.
Maybe 2 or 3 weeks before, the main hub got locked, but here I had to restore a backup on a spare hub because it got frozen in initialize at 50% and nothing will make it pass 50%, after restoring in another hub this spare hub booted fine, then happened the lock a few days ago.
My opinion is maybe the upgrades are causing some kind of damage in the db not noticed, the only way to fix it is starting the hub from scratch. My second hub with xiaomi is working fine but I started this hub from scratch the same day as I swapped the main hub.
Here is when I believe we need more tools to diagnose this ourselves, but per HE they are not needed.
This part is for @srwhite, I had another issue with ghost nodes in the z wave mesh, I always noticed when I used all my lights in HSM for alert they will lag to turn on all of them, or a group with all the lights, but using the same USB stick in zensys, if I click turn on all, everything will turn on instantly, no lag. Could you explain why this happens? It's clearly something in how the messages are going out to the devices or maybe the messages coming back to the hub, but with zensys there is no lag to turn on or off everything at the same time. Sorry to bring this here.
Zensys tools makes use of a Z-Wave command class called COMMAND_CLASS_SWITCH_ALL which works similar to a Zigbee multicast in that it instructs all devices that support that command to switch on or off depending on the payload included.
You will get some lag controlling multiple individual Z-Wave devices which is to be expected since each device is being controlled individually.
Thinking about it, I was trying to figure out what had possible changed, and the only thing I could recall for me was that I deleted Life 360 from my phone, but did not remove it from my Hubitat. Now I don´t know if this is related (doubt it), but you never know.
One thing I have noticed regarding ‘cloud’ based apps/drivers
If the ‘cloud’ is unavailable or unreachable for any reason this produces loads of errors in the internal logs and can slow or stop the hub..
It sits there trying to contact the cloud, waiting for a response.
This could be the reason for your issue, by disconnecting L360 on one side, the hub would still try to connect/control it.
That was along the lines what I was thinking. But instead of this happening, could we build in some kind of failsafe to either alert of such a condition ( i.e. show devices with excessive errors) or have the device fail if it presents errors for too long a time ?
