Automatic reboot, done right, (via reboot command, vs pull the plug) is mostly harmless. I can certainly see that doing so DURING the nightly maintence window (2am+) would be harmful.
Is it desired. NO, Should we need to do it? No, Can it be done if it alleviates pain while the individual causes are found and squashed? Absolutely your choice.
Will a 2nd (or 3rd, 4th or 5th) Hub solve it? Less certain. If you have the $ available to buy one (especially in the next few hours while the sale is on) DO IT. Just having a spare, in a box, in your house, no shipping time, has got to be value enough, in my opinion. That you can ALSO use it to test if splitting the load helps.. what is that tag line... "priceless." Put it back in the box as a spare if it doesn't. 
Other than the $ outlay, I can't see much downside... (says the guy with 6 of them) Just knowing that the whole house won't fail entirely due to one bad USB connector is (again) more than enough for me. My development pair are ready to be sacrificed to the Production set, should any failure occur. (My production set are C-3/C-4's with the external radio, so I anticipate a very short outage.)
I'm focusing on one word there... "solution" and that's because I don't think we can predict the outcome. However, I agree that I'd be trying that if I were in your shoes. 
5 Likes
Exact as @csteele is saying. Do it at 3:30am when youāre well past the database backup time, and no one really needs the hub.
I reboot every night on one of my hubs now, at 5am. My other hub at a different property doesn't seem to slow down much so I'm not rebooting it regularly. After the reboot, I re-initalize and refresh all the Google Home devices and since they are on fixed IP addresses they seem to reconnect nicely. The reboot is really quite painless although of course we'd all prefer to get to the bottom of why some hubs persistently slow down.
The one thing that I smile at is why the Hubitat team would think that 2am is an appropriate time for the maintenance function to start without allowing us to move that time. It slow my hubs down to a crawl for several minutes. 2am is NOT the middle of the night. It is the earliest we get back after partying at the weekend 
1 Like
There's always someone who leaves early. 
4 Likes
Do you think part of this could be caused by some weird interaction between ZW/ZW+ devices on same network where the ZW devices are acting as repeaters?
I'm wondering since I realized I had like 8 Aeon Micros (ZW) with some in prime repeater position (closest to hub) throughout my main floor - had them for closet lighting, basic switching etc. Never really noticed an issue until I started adding ZW+ devices... but I can't really be sure.
I think thereās been reports from those that donāt have any Z-Wave devices too. Thereās any number of issues that could be behind it. No single cause has been determined.
yeah complex systems are complex! 
I know there are a lot of different factors of course but the zw/zw+ thing seems to be a relatively recent (possible) issue for me.
Swapped out 2 of Micros in my main floor closets yesterday with RGBGenie ZB switches. It's still a little early to tell based on this change but the Hub did not reboot last night. I am also going to replace the other zw switches nearest to the hub with zw+ switches.
I'm kind of bummed those Micro G2 switches have been working really well** for over 5 years. Maybe I need a separate hub for only zw devices haha.
** for the rules that have been created for them.
1 Like
Well, I have been running HE since shortly after the launch with no hub slowdowns, til this past few days.
I updated to 2.1.9.115, added a couple new GoControl switches, added a new Iris 3210-L plug, healed the Z-Wave network, shutdown the hub and pulled power for 30 mins to force the Zigbee rebuild. About an hour after firing it back up, the hub was locked and no response from anything, hub blue light on and steady
Last night we came home again to nothing responding, blue light on the hub, took over 2 mins for the hub main page to load. The hub did respond through port 8081
Log shows tons of errors from Echo Speaks v3 during the previous 4-5 hours
This is a first for me
C-3 hub, 2.1.9.115
Running a super clean hub, with very few apps/drivers outside of built in stuff
Sure hope they find answers real soon
I've been monitoring my hub response using @bptworld's Hub Watchdog and have found that my hub slows down every morning just after 2am. I don't know what causes my hub response time to spike, but I do know that the hub doesn't really recover from the event and becomes less responsive over time until I reboot it. You can see where the response times drop back to pretty much a flat line, which was after I rebooted the hub.
I've looked through all my devices and apps and none of them have a daily scheduled task around 2am. I'll continue monitoring the situation and hope to pin down the cause of these issues. Let me know if anyone has clues about the 2am spikes.
1 Like
Thatās the database maintenance time
3 Likes
Yea that is the DB maintenance time...but it is a pretty clear pattern that the hub slowly continues to get slower right after maintenance. After the reboot it stays pretty flat until maintenance happens again..then starts slowing down. I call that a very interesting find!
1 Like
Imagine if you maintained your car and then it ran at 1/10 the prior performance. You'd be back to the garage in no time. This persistent hub performance issue is a real pain.
2 Likes
That's about when the Rootn Tootn Rebootn app reboots my main hub - usually around 3 am.
1 Like
Yeah, but imagine the look the mechanic would give you if you said you donāt want to just restart your car in the middle of the night when youāre not even using it, even though that totally fixes the problem. 
1 Like
Ha! As long as I can restart it automagically!!!
I guess the worry is something else is going on that we don't understand so reliability/stability becomes a concern across everything.
3 Likes
Maybe, but thereās no evidence either way at this point other than, hub gets slow, reboot, fixed.
But that is not normal expected operational behavior right? So yes rebooting will take care of the issue - but it's a stop-gap measure not a solution. Admittedly I've been running with hub reboots and things have been working so have been relatively happy.
My thinking is a lot of issues are caused by devices on the network not necessarily the hub itself - there are so many different kinds and their behavior can impact the network in a lot of ways.
I just wish there were more clear ways to troubleshoot. Diagnostics page/reports that flags certain potential issues rather than me having to parse (badly) through ChildAndRouteInfo reports and Z-Wave arcana.
Being able to easily locate potential troublemaker devices would be wonderful..
I'm new and new to this problem. I got through 10% of trying to write a simple rule last night before I gave up entirely. Several questions:
Does rebooting the hub have any additional downstream work or reconnecting?
Has anyone tried isolating (control testing) to certain actual rules? Maybe it's a feature of RM4 that we're all using? Just a thought. I saw a thread where one guy solved his issue by removing a device, but it may have been a rule it was sitting on. Just a thought.
Also, how has this not been solved yet? Looks like it's been an issue since 2019? Not to be controversial, but there's so much competition in this space, and the one thing that brings people here is an active community. If you allow problems like this to impact adoption of devs, isn't it basically game over?
1 Like
For sure and that is what I meant when I wrote, āEventually theyāll get to the bottom of the issueā. Personally I think itās really not a big deal that the hub needs to reboot in the middle of the night. Iāve used that functionality with routers and ISP modems to keep them running well, so thereās no reason it should bother me here.
And actually those companies had much less of an excuse because they were huge companies with thousands of staff. This is a small team with lots of good stuff going on behind the scenes and a lot of faster growth than any of them could have anticipated due to the quick shutdown of IRIS, fast decline of Wink, and failure by SmartThings to keep a large number of their existing user base happy and their cloud stable.
Would be nice if people would just do these simple things to give them a breather, trusting when they say they are working earnestly towards as stable a platform as they can, and stop standing on their heads 24 hours a day, hurtling negativity, distrust and disparaging remarks at them and their hard work. This is not a comment directed at you personally though. Iām just replying to you because I mostly agree with you and just want to share a different point of view towards the situation. 
6 Likes
If you suspect an app or driver, you can disable them at any time by just checking a box. Devices are much more difficult to troubleshoot.
https://docs.hubitat.com/index.php?title=Devices
https://docs.hubitat.com/index.php?title=Apps
Rebooting will not force you to have to fix anything or reconnect anything.
1 Like
