I have a scheduled reboot of my hub each Thursday at 4am. This has worked fine for a long time, but recently, without fail, i’ll wake up Thursday morning to a broken zwave network (devices don’t respond, but the hubitat ui shows the state changing). I then do a reboot from the ui, sometimes twice, and then it all starts working again, until the next scheduled reboot. I’m wondering if anyone else has noticed something like this, recently?
1 Like
I do have a scheduled reboot on Sunday mornings because of slow downs I use to experience several platform versions back. I have a lot of Z-Wave devices and they seem unphased by the reboot.
Assuming you have a C7 (latest revision) hub, you may want to take a look at your Z-Wave Details screen to see if any devices have a “Discover” button - that would indicate that the devices didn’t join properly and are considered “Ghosts”. These will cause issues with your mesh, and should be removed. There are a lot of posts about this.
Other things to look for are devices joined with S0 security. S2 can also be an issue, but S0 is the most problematic one. “None” is preferred for non-security devices (like locks).
Other than that, there are some devices like the older Zooz 4-in-1 sensor that can cause havoc with the mesh.
Hopefully, this will help you determine the cause of the issue. Welcome to the community!
1 Like
Thanks for the ideas. Unfortunately, I one all these typical pain points all too well. The zooz sensor was a really fun couple days lol. zwave mesh looks good, and this only happens after the auto reboot, never before.
I do have a c7, and I too enabled the reboot because of slowdowns about weekly. I wish I could point to the exact hubitat update that started all this, but there are so many and I stay up-to-date.
This certainly became a thing within the last two weeks (2 reboots and two dead zwave meshs). The zigbee side of it seems to keep working. Given that the only variable in this is the hubitat firmware update (nothing has changed zwave wise), that’s why I took the time to post.
I’ll be curious to see if this is an issue that only i’m having, or if others with a similar setup and process have also noticed. For now, i’ve disabled the auto reboot and i’ll just keep an eye out for slowdown and manage it manually.
1 Like
Sounds like database corruption. Start with disabling reboots. It should largely be unnecessary. Go to Settings>>Backup and Restore and click the download button and save it to your PC. yourhubip:8081 and do a soft reset, when asked, restore the database you saved to your PC in the previous step. Once complete, go back to the settings menu, shut down the hub and then unplug (at the wall not the hub) for 20 mins to clear the z-wave radio and power back up. See how things go.
Can you PM me your hub's id? I can take a look at the engineering logs on the hub.
Unless you've verified that all things being equal, the hub does not work properly w/out the weekly reboot, I'd remove that. I used to reboot my hub on a schedule, haven't done that for many months and things work smoothly. YMMV of course...but verifying if the reboot is still necessary could be useful and potentially simplify things for you.
2 Likes
Hm, I just ran into this problem. I rebooted from a webcore piston that just calls [hubIP]:8080/hub/restart and Z-Wave devices didn't respond. I rebooted from the UI and they still didn't work until I operated them manually first. (Not relevant, but I had a low memory warning after 35 days uptime, so I wrote a rule to automatically reboot when memory is low.)
Shutdown hub from settings menu. Unplug power to hub (from wall not hub) for 5 mins and power back up. That may clear the behavior. I've seen similar with a corrupt radio.
