My hub has downright locked up, stopped automations, and the admin interface has refused to come up 3 times since the 2.2.7.125 update.
What can I do to troubleshoot this. And what is the process for rolling back release versions?
2.2.7.125 is a stable release.
But, to roll back, go to http://{my-hub-ip}:8081
There you can restore a previous version.
Okay, help me through the process of elimination.
Hub operating stable, no unepected automation ot admin page stoppages / unavailability on prior versions.
2.2.7.125 installed
Hub randomly stops all automations / tie ins to Alexa, admin page stops responding. Required manual power cycle of hub to restore service.
What could the issue be?
Rolled back, and monitoring the situation. I am now on 2.2.7.123 which was the last known good configuration.
I somewhat doubt this has anything to do with 2.2.7.125. The latest build is 2.2.7.126.
I'm open to ideas... Seriously.
It is possible this is coincidental. I am seriously looking for how to troubleshoot this...
I'd start with a Soft Reset.
DB errors can reveal themselves in mysterious ways.
Take a LOCAL backup now or rely on one from earlier.
Use the Diagnostic Menu to perform a Soft Reset. On reboot, you'll end up at a Hubitat start screen and subtilely at the bottom is Restore from Backup. Pick that and use the latest backup.
You can always roll back further too.. use a week old backup. You'll lose, of course, everything that you or the hub did after that moment in time, but perhaps you did nothing critical.
A little bell is going off in my head that you've done Soft Resets before.. and if true, sorry for the repetition of the steps. Maybe you're not the only one and one of the Lurkers will benefit. 
A Soft Reset in my experience is low risk, has never seemed to hurt and is quick to implement. In other words it's one of those things we all should become experienced with so that when it's critical, it's also familiar.
5 Likes
Bad power supplies can cause erratic symptoms like this. So I'd suggest you check the power supply (Any 5V power supply that can output 1A or more is ok to use).
3 Likes
I see plenty of cloud disconnect messages starting on 5/6. Was the hub plugged into a different router or was there any other network change around that time? If network connection drops, the hub will not be accessible, including port 8081.
There are a few endpoints in latest 2.2.7 that may help with reconnecting:
/hub/advanced/enableNetworkWatchdog - enables a watchdog process that frequently pings default gateway and attempts to reconnect using DHCP if network dropped
/hub/advanced/disableNetworkWatchdog - disables the watchdog process
/hub/advanced/isNetworkWatchdogEnabled - shows whether watchdog process is enabled
The issue may be elsewhere, but since there clearly is a connectivity issue, it's worth a shot.
2 Likes
Isn't the Hubitat supposed to do its thing on the local network and not rely on cloud services? I mean it is one of the claimed selling and marketing points after all...
Yes, our broadband does go up and down from time to time, on 5/6 Comcast / Xfinity decided to "up our connection speed" and since then connectivity has been flaky.
And without a doubt I likely need to update my DD-WRT version on my router.
Yes, and I view those disconnect messages as an indicator of network being up/down in general since there's no other indicator. Enabling the watchdog will produce another set of log messages showing if/when connection to the router/default gateway drops. It could not be a problem at all, but we got to eliminate one issue at a time.
2 Likes
Well, FWIW, latest DD-WRT build downloaded and getting ready to do the overdue updates...
I have seen generalized flakiness in various 2.2.7 Patch releases. Things that had previously worked became intermittent, or very much delayed.
The oddest was a Zooz outdoor double outlet. I use one side for a sunset-to-sunrise outdoor lighting scenario (other is currently unused). Has been super solid. Until a couple of days ago...
Then it lost its mind. It got into a mode where it would turn off 5 minutes (to the second) after turning on. And this was independent of how it was turned on - by sunset rule, dashboard, physical. it would shut off. And it would claim that the shutoff as a Physical event which, of course, it was not.
In addition,for the few days it was weird, it would turn on in the 2:30AM timeframe (not the same time each of the days) and turn off exactly 5 minutes later. Just once per night.
The only things I had done were to look at it on the iOS app and turn off the other outlet, which seemed to be on for some reason, and make rooms and add this to a room. Then it went into left field.
Deleting the rule did not fix it. Further upgrading from Patch 2.2.7.124 to 2.2.7.126 did not.
Finally had to delete the device and re-pair it. Seems OK now.
The other issues, as I said, are intermittent failures of devices to actually follow their rules- the rules go and nothing happens.In one case, the device (outlet) was actually on, but the Hubitat system claimed it was off and had never switched on.
At the moment things are working. But 2.2.7 seems a bit wonky overall.
Cheers.
1 Like
And no hangs / crashes since rolling back.
I may be close to that myself after another miscue today on 2.2.7.126. Pushed a button, and button records that it was pushed. Response unit has no record of the event. subsequent push of a different button for the same unit worked fine as did an earlier push of the same button today, according to the logs.
Cheers.
I have been having the same issue. I just decided to roll back today. I should know in the next 24 hours if rolling back fixed it.
No hiccups at all since the roll back. Now to keep the peace I am not going to say the revision I rolled back from was unstable, but I WILL say prior to that release my hub operation was solid as a rock, post update to that release and the hub crashes / becomes unstable, roll back off of that release stable as a rock...
Same here strange all previous updates always seem so good from HE but 2.2.7.126 seems to lock my HE up after running a few minutes which is not ideal.
I have a few Arduino based Devices that send quite a few events. This has worked fine for months now running my HVAC and ventilation perfectly.
The devices highlighted are all Arduino ones, many with 6 plus events all using HTTP GET
Here is ERV DAS one of those "eventy" drivers I mentioned
//ERV DAS
attribute "InletFanOn", "Boolean"
attribute "ExhaustFanOn", "Boolean"
attribute "StaleTile", "String"
attribute "StaleTemp", "Number"
attribute "StaleHumidity", "Number"
attribute "FreshTile", "String"
attribute "FreshTemp", "Number"
attribute "FreshHumidity", "Number"
attribute "InletTile", "String"
attribute "InletTemp", "Number"
attribute "InletHumidity", "Number"
attribute "ExhaustTile", "String"
attribute "ExhaustTemp", "Number"
attribute "ExhaustHumidity", "Number"
attribute "LoftTile", "String"
attribute "LoftTemp", "Number"
attribute "LoftHumidity", "Number"
attribute "Packet", "Number"
attribute "RSSI", "Number"
attribute "Analog", "Number"
attribute "ExhaustStaleTile", "String"
attribute "ExhaustStaleTemp", "Number"
attribute "ExhaustStaleHumidity", "Number"
attribute "FreshInletTile", "String"
attribute "FreshInletTemp", "Number"
attribute "FreshInletHumidity", "Number"
attribute "DeltaP", "Number"
attribute "TempsMax", "Number"
attribute "TempsMin", "Number"
attribute "TempsMean", "Number"
attribute "TempsDelta", "Number"
attribute "EngineeringTile", "String"
Then 2.2.7.126 went in and all hell broke loose keeps hanging and the like which not ideal.
I restored 2.2.5.131 and all is well again
I'm wondering is the update to 2.2.7.126 causing an issue? This sort of thing used to happen a year ago when I first started writing drives but was rectified by an update at some point.
Does the hub have max device states/events set to 10 or lower by any chance?
(If you don't know what it's about, it doesn't)
For mine, not a clue, so I guess the answer is no...
