Updating fixed the error at 875 issue for me, thank you.
Yes, I'm on 2.6.13.
I must admit though after a rush of these errors on all 3 hubs it looks like they have stopped now.
Thanks again for the driver.
Why would I be getting 1024 errors from dashboard if I'm on the latest version?
It’s caused by bits floating around from the version that had the issue, triggered by today’s firmware update.
Easiest way to fix is to delete Hub Info driver (watch out for in use by stuff that uses the driver), then reinstall (preferably by HPM). That causes Groovy to clean everything up. I had the same issue.
If you are still showing a value for hubUpdateResp check to see if line 91 reads:
static String version() {return "2.6.14"}
After line 270 add
if(hubUpdateResp) device.deleteCurrentState(“hubUpdateResp”)
Save and then go to the device and hit Configure
Looks like they got converted to "smart" quotes. Try to get the plain " character, or you could use ' instead if that is eaiser (as long as it's also straight).
Thinking on it you may need to change the if to
if (device.currentValue(“hubUpdateResp”))Just saying …
Over the last 2 days - I've been having strange behavior - Hub app on the android reporting in debug that cloud.hubitat can't be found (android presence failure) and other things but this one seems more strange:
However, hub is showing an update available (see sys msg in top right):
Any ideas?
This could be to do with the pulling of update 123. I noticed that my hubs were showing the red (1) dot in the System messages, but when you click on it, it would then detect no update available (I'm running 2.3.0.121). I considered raising it with the HE dev's, but thought I'd leave it for now, it is Christmas 
3 Likes
.123 was pulled due to a small bug, message can be safely ignored…
1 Like
@sburke781 I hear you. Bravenel thinks all I do is bash his baby so I figure posting is a bad thing - I'm keeping my posts to a minimum FNO!
5 Likes
Oh, I didn't mean anything by my comment, for you or Bruce, only that I didn't want the dev's to feel it needed to be fixed straight away. In hindsight I should have just raised it and explained the urgency from my end, leaving it to HE to decide how quickly it should be fixed.
1 Like
2.16.5
Have added the option to allow Hub Monitor to reboot the hub if the IP address changes to 169.254.x.x. Option is a per hub setting and appears after setting the Alert on IP Change to true.
To make sure you really want to do this, the Hub Information Driver must also have it's preference set to true.
is there a delay on this becuase obviously when hub firsts boots up and tries to get an address via dhcp it could be this ip for awhile?
Configurable option in Hub Monitor, along with a maximum number of retries to keep the runaway possibility at bay.
3 Likes
Is there any way the status of the Zigbee and Z-wave radios could be included? I had my hub’s Zigbee radio go down and would like to auto reboot the hub in that circumstance.
2 Likes
Well, you could create a Rule with Trigger events of Location Event, zwaveCrashed or zigbeeOff.
1 Like
Oh wow, I didn’t appreciate either of those were available. Is there a zwaveOff of just the one you mention? Strange they used such different terms.
