So, not reporting a problem. Just asking a question as I am reading through as much of the form as I can get through. I am seeing a lot of posts regarding 2 AM local maintenance that supposedly creates backups at that time.
My question is, should I see those backups in Settings>Backup and Restore? Because I do not see them at or near 2 AM. I do see them at 3:30 AM (Which is when I have daily scheduled reboots)
Is the maintenance taking an hour and a half and that is why I am not seeing them? Do I have my reboots too close to the maintenance time (potentially causing an issue?) I do the reboots at 3:30 because I am usually up at 4 and that seemed the most convenient that would not interfere with the maintenance. Just asking in case I need to move my time around the maintenance schedule.
These backups are generated automatically and stored on the hub for five days. Each day we automatically generate a backup at around 2:15am and if you reboot your hub. You will only have one backup per day stored.
So you are overwriting the nightly backup by rebooting.
And I am still only 2 weeks in (But still loving it) Just making sure I wasn't putting my reboots too close to the maintenance window (BEFORE I have an issue because of it.)
Is there are reason you're performing daily reboots of the hub? I could possibly see once a week, but daily seems a little bit excessive. I have been running on Hubitat since February 2018, and I have never scheduled reboots of the hub. I know others have, and for good reason, but I've never felt the need.
From my reading, it was a preventative measure for slowdowns. Once I got through tinkering, my plan was to turn that off and find out if there was a slow down issue and if so, what that threshold was.
For now though, I am making changes and tweaks every day. So, just letting any junk that may get built up a chance to get cleared in a reboot (won't mention the loop I accidentally got caught in while tweaking the one app I was playing with to learn..... wife was NOT happy with me for making all the speakers in the house go off about 50 times in less than a minute.... BUT I have a good idea for an intrusion alarm that we won't sleep through LOL)not really..... but it sounded funny
The problem I see with this technique is that you'll be 100+ changes in before you disable nightly reboot.. and you'll have NO Clue as to how to fix it. You would have to undo 99 of them just to narrow it down, then put them back in sets of 10 to focus in...
That's assuming you have all the tinkering documented (I already know that "tinkering is never documented )
Unless you're experiencing issues, I would suggest not doing nightly reboots. The nightly maintenance should help clean anything up from during the day, but if you have any issues after that, then you can look into a reboot schedule. If you add more to the device, then it will add more load to the hub. To do the reboots under a light load but then remove it under a heavier load sounds counter-intuitive
It’s true that regular rebooting has been used by those of us that have run into seemingly intractable hub slowdown/lockups that couldn’t come up with a more specific resolution.
However, in the last year or so they have done a ton of platform updating and I believe it’s much less common for users to need to do this these days. I know I don’t have to do it anymore.
So I agree that doing it on a relatively new hub that hasn’t experienced major problems, mainly as a preventive measure, is likely unnecessary.
Actually, my tinkering is 100% documented. And, I am making limited changes each day according to a specific plan and then observing for a day for any issues. So, for instance, I added a single device type, and put them on automations, then tested those automations for expected functionality. THEN, I let them sit till the next day testing as possible and made sure they were acting as expected. Even though I have over a hundred items, I have only 14 device types. Having spent a few years on ST, I learned what specific things usually caused me problems over there and am working to a specific plan and checklist. Started with extenders, both Zwave and Zigbee, then bulbs, then switches, etc. Moving over from ST while using hub connect until all my items were over and I disconnected hub connect and then removed the hub connect apps. Then, I started with the apps making tweaks for the small differences between the platforms. This is more tedious, because I am only changing on thing a day to make sure I can isolate any issues. Also making local backups at the end of the daily testing period named with the change from the prior day.
This is how my brain works though. I do not do anything without a specific plan and checklists. Working in the Scientific and Quality fields, I also do not do anything without documenting every little step I take so I can backtrack.
Interestingly, i haven't run across ANY of the Zwave issues others have mentioned (specifically with Kwikset Locks and GE Switches). Maybe because before I started, I searched every different device type and searched and read every post I could find about the potential problems and the solutions. Additionally, many of the issues on HE that were posted about were also encountered on ST. So, I was familiar with them to some extent.
Wasn't really asking for advice on the reboots. Just why I wasn't seeing the backups. I know the nightly maintenance is supposed to clean things up. But, there are also several posts about how it may actually slow the hub down until the next reboot as well. So, I am eliminating that until I have everything settled down with reboots. Once everything is done and working as expected, I will pause the nightly reboots and observe. Then, depending on how the hub does over time, I will set the schedule as required (or even if required). However, there are ample posts stating that there are slowdown issues and a reboot seems to prevent/rectify. Not much different than needing reboots on the older versions of windows (and even on the current version depending on the machine specific hardware - I have two dells that will drop Wifi unless they do a reboot every 24 hours - should I have to? no, Is it a work around? sure. Am I going to keep doing it as long as it's fixing the problem? absolutely)
Sounds like you’ve put a lot of thought into this process.
I would just emphasize that it appears you’ve implemented a solution for a problem you haven’t experienced, and in the last year the platform has been updated significantly to try to address the possible underlying issues that result in hub slowdowns (thus obviating the need for affected users to regularly reset in order to avoid it).
So I understand you don’t want to change too many variables at once, but I would suggest keeping this at the top of your list, because it’s probably just unnecessary.
(I already know that "tinkering is never documented 
)
