I currently have a RM rule that detects when the system starts and performs some actions.
After today's freezing rain/ice pellet/thunderstorm combo and power outage associated with that, I am looking for a better way to determine why the system is restarting/starting up.
If the system is restarting because of a software update, I don't want it to do certain actions.
If the system is restarting because it is recovering from a power outage, I want it to do everything.
I was hoping to be able to detect something like a systemShutdown event and set a variable of some sort to indicate that it's a controlled restart versus a power outage, but I don't see that option.
The hub does not have a way to know, and from what we've been told, this is unlikely to change (some have asked for a way for apps to subscribe to a "shutdown" event, but the process begins as soon as the command is sent, so there would be no time to do anything even if there were one). However, because any planned shutdown would be a user-initiated action, there are things you could do before that--say, setting a variable or turning on a virtual switch, or however you want to keep track of this (or creating some automation to help you do the same via more convenient means).
As an alternative: if you put the hub on a UPS, which is a good idea for other reasons (e.g., avoiding the possibility of database corruption from a power cut), then you could more safely assume that any shutdown/restart was planned. That's the easy option, IMHO.
Is this more based on down-time? Like if a power blip caused a reboot but it was only down for no longer than an update would that qualify for doing "Everything" or just the same as a reboot from an update?
I was thinking you could have a RM that updates a variable with the current time every minute or every couple of minutes.
Then your system Start rule could check how long the hub was offline.
Only problem may be if the variable gets updated after reboot before the system start rule. Could possibly avoid that by having the rule that updates the time run every 5 minutes and then a 4 minute delay inside the rule, so that gives enough time to run the other rule before it updates after a restart.
While they do support restoring their previous state when the power comes back on, and that is working for bulbs that were actually on, what's happening is bulbs that were off are coming back on in a dimmed state but not really on.
Looking in Hubitat, the switch state of the light is off, but the bulb is actually on.
Today I ended up using the mobile app to turn all of the affected bulbs fully on, then off.
Based on bert's advice, I've added a virtual switch to my setup and will just need to make sure to turn that on when I'm doing a software update, otherwise I'm going to get the stink eye from the spousal unit
My latest systemStart logic is to turn all of the bulbs off when the virtual switch is off, then execute "resume rules".
If the virtual switch is on, just execute "resume rules".
You may have thought this through already, but if not and you run with my idea: you may want something to turn off this switch after the hub starts normally (though perhaps not right away if you check its state) so it's ready to be turned on again. I skimped over details, but that was my general idea.
If only @gopher.ny would give us an endpoint that returns the platform version as a string. Then you could set a variable to the current version and check if it's changed at startup to differentiate between a platform update and "something else."
Hub Info Driver could do that (or other ways to scrape the data--just haven't seen any), but you'd still have the case where you just decided to reboot for...fun?
I had an issue a couple weeks ago when updating and things went a bit sideways between the hub restarting and the info driver completing it's own startup.
That's the easy option, IMHO.
