No but I’ll give that a go.
Will that require me to re-pair my zwave and Zigbee devices?
I don't have hub protect, but with normal backups you can change the backup intervals. I have mine set for 3 days now, but I am thinking of going weekly now that I have things working well.
Can you not set that interval with hub protect? (I don't have it) If so, it seems like that should be a feature request. Even 1-2 times a month would be plenty often to do this type of backup in my opinion.
2 Likes
No. It “cleans” the database - nothing is lost.
1 Like
Yes, with hub protect I can choose the interval. Default is weekly. I changed mine to daily because I'm still setting things up, but once I'm mostly done I'll go back to weekly.
2 Likes
Obviously the best outcome (I expect) would be a solution within the Hub Protect offering, whether it be an adjustment to the configuration or making some kind of feature request. If you want to expand on what it offers however, you may want to look at downloading and managing the retention of backups locally and/or in the cloud, such as setting up scripts to run on a raspberry pi or PC. Not the polished and convenient solution I expect Hub Protect may be, but an option nonetheless.
Cheers.
Btw, one thing I noticed was a few Rule machine rules stuck in “repeat” loops - I wonder if Hubitat needs some way to reset rules after a reboot to ensure they start up cleanly?
It’s a bigger issue than that, and it bit me last week when @thebearmay was making hourly updates to his Hub Information driver. I have a bunch of rules that have critical regions with Private Booleans controlling entry and exit to Repeats, etc. If a backup / soft reset / reboot is taken at just the right time while one of the Repeats is waiting on a condition to terminate, or a critical region has Private Boolean false, it leaves things in a mess. The only way I could figure out to make everything right, reliably, was to put in a fairly extensive systemStart rule to initialize things, cancel Waits, etc.
It seems, if Hub Variables are being re-worked as a replacement for Global Variables, that each one should have an enabling switch that, if enabled, would initialize the Hub Variable to a given initial state on systemStart.
Perhaps that’s something that @bravenel might consider.
1 Like
That’s why I abandoned them, every time my hub restarted, at least one would break turning that rule into a zombie.
I’ve found repeat loops to be less prone to this issue.
2 Likes
I wish you realized that this is an outlandish suggestion. You can do whatever you need at System Startup with a rule, there doesn't need to be some additional special overhead for Hub Variables.
There is no magic bullet for the problem you have described, except, it's a pretty loud endorsement for KISS approach to automations. With simpler automations, this issue becomes pretty much innocuous. There is never going to be some clever magic to capture the hub state, 'fix' it, then restore it exactly how you want it. This is not unlike a restore point in an OS. It's not all roses -- it will put you back to a prior state, but that is not necessarily exactly what you want -- but it's what you get and presumably is better than nothing.
Thank you Bruce. Your disdain for your customers continues. Have a great day.
How can we reset all in-flight repeat actions at start up with a rule? This would be useful.
Not disdain, just realism. Can't pretend that every customer idea is golden. You have a great day!
1 Like
The rule would have to make provision for it, e.g. a trigger on System Start, and have some way to know that was how it was triggered unless it automatically resets everything on any trigger. Reboot of the hub, while it throws an event, doesn't change the then current state of the database and running automations. Automations, in general terms, are defined by the 4 elements of their state (Settings, Event Subscriptions, Application State, and Scheduled Jobs), all of which are in the database.
The case of "stuck in repeat" is basically the issue of some scheduled job's time happening while the hub isn't running, and then "waiting for Godot". Consider the options. You wouldn't want to run through every missed scheduled job and run it on startup. If there is some solution to this it's escaped us for over 4 years, when we first began considering how to deal with it. For many automations, resetting them on startup would be entirely the wrong thing to do.
Realistically, taking down an event driven system mid-stream, and then bringing it back up is going to present difficult issues. Given that most of the subsystems are user written automations doesn't make it any simpler. It seems as though you're stuck one way or another with an imperfect outcome, because the only perfect one would be that the hub had not been down at all.
We have put a lot of effort in over the past several months dealing with things that might lead to the need to reboot the hub, trying to eliminate them. The best solution is for the hub to stay up 24/7. We will continue to hunt down and resolve any leaks or other issues that lead to a need to reboot -- there should not be a need to reboot. You can see some of the work that's been done showing stats about the hub, all part of this effort. This remains a top priority.
After such a long outage, one thing you could do is open rules that have repeats, Stop them, and then hit Done. That makes the rule brand new as if just installed.
That's pretty much what I've done.
This has certainly paid dividends, I was having to restart services daily and reboot weekly - On 2.2.7 I no-longer need to do this.
If the hub performs strangely after an accidental power loss and an extended power outage, there are two things you might want to consider, if you haven't already:
- Make sure that internal clock is updated (go to Settings then select Hub Details and click Update Time from browser
- Perform a Soft Reset with restore following these instructions:
https://docs.hubitat.com/index.php?title=Soft_Reset
I wouldn't try to restore a backup from before the update, but rather take a fresh backup or use one of the 5 local backups that are saved on the hub.
And speaking of 5 backups. Hub Protect offers up to 5 cloud backups. The customer controls the frequency, so the 5 can be 5 days, 5 weeks or 5 months (or any other combination). The advantage of only 1 cloud backup is that if the hub didn't come back after the power outage, and you didn't have a local backup saved, you wouldn't be able to access the local backups stored on the hub, so all rules, apps, drivers would be lost. With Hub Protect, such catastrophic consequences are avoided. That is the purpose of Hub Protect in the nutshell.
1 Like
Any chance this could be increased to 30 backups? The files are tiny (~3mb for my C7).
That wasn't an issue.
Ok, going to do that now.
Ok, that went smoothly - hopefully it'll return to normal reliable operation now.
1 Like
Thanks Bobby, my Primary C7 is back to it's old, reliable ways. 
1 Like
