My hub had a fault yesterday. It got hung and I had to restore from a previous backup. The hub stopped logging at this point and didn't start logging again until after the Restore was completed.
Some of my hub variables have the next date and time to run a specific rule. I have a Initialization rule that is triggered by the SystemStart Location event that updates these hub variables to the current day and to the next time for ones that run multiple times a day.
All of these hub variables were still set to the old date and time. Manually ran the Initialization rule and the variables updated properly.
Am I correct in thinking that the DB Restore is followed by a reboot?
If that is the case, shouldn't the SystemStart event have triggered the Initialization rule?
Yes a restore does a reboot so it should have triggered.
You might need to add a delay to the rule, the SystemStart might be triggering too early in the boot.
You could turn on logging on the rule, then manually set one of the variables incorrectly, like something in the past. Then reboot and see what happens.
Good call by Jeff on the timing...
I use a 2-minute delay, and that's always worked well for me. Maybe I could shorten that, but I'm too lazy to experiment.
I also have a Log line as my first action -- that gives me a warm fuzzy knowing it all triggered properly and could assist me with fine-tuning the delay in the future (if I ever get motivated to do so).
Thanks for the ideas.
My boot app waits until Hub Information Driver shows CPU utilization under a threshold before running each rule.
Think I may have found an issue in my logic. Did both local and Cloud backup after the fix.
Will wait a few days then do a restore to test my fix.
Cant you just turn on rule logging, change one of the variables to be backdated, and then reboot. Seems like that would work to test it?
That would work too. I"ll try that now.
Did a reboot with some Hub Variables set back in time. All variables were reset properly. Thanks
