Please add a Shutdown event to the list of Location Events.
Currently the System Start event occurs after the hub starts to execute apps and rules.
My use case is to flag my RM rules to skip executing during shutdown and system start until all of my system start rules have been executed. Rules that runs frequently can be skipped. Rules that are triggered by occasional events or don't run frequently are paused until startup is complete.
For example, my window shade levels are updated every 2-3 minutes. It is not a problem to ignore thesr updates during a system start. An hourly system check can easily wait a couple minutes to execute without a serious effect on the results.
I have been doing this in Tasker for years because some device events get repeated during a system start.
The second use case is to keep the RM Rules from acting on non-events.
It’s a 5 minute job, Bobby. The events already exist, they are manualReboot and update. If I’m not mistaken the op is only asking to add them to the combo box in RM.
When shutdown happens, things are about to, well, shut down.
I can add a shutdown location event, but be aware that there is going to be a very limited, and potentially unreliable, window to act on it. If the hub is busy, it may never get to executing whatever the event triggers.
Just want to make sure everyone understands this and is ok with it.
My use case is to set a Hub Variable that I use to show where the hub is in the boot process.
This variable is used to pause rules that run infrequently so they can be run when the hub is ready or to stop rules that run so frequently that missing one execution is no big deal. For example, my window shades change positiin every 2 minutes as the Sun moves.
The systemStart event actually occurs over a minute after built-in and community apps start executing. RM rules can be triggered during that time.
Since the system services are not fully operational, several apps spew out numerous error messages. Maker API is the most prominent of these.
My other use case is to use an HTTP call to pause Maker API until the systemStart event.
It would be great if the Hubitat devs would modify Maker API so my second use case would be unnecessary.
To me, this thread reminds me of "Give a mouse a cookie". For anything meaningful to "not happen" or for a rule to run to turn things off or whatever, there is needs to be a practical window. For a practical window, there should be some delay to actually reboot. If there is a delay, it will be requested to be configurable. If it's configurable, there is a new setting somewhere. If there is a delay, during the reboot, there will need to be a countdown timer. If there is a countdown timer, there will be a request to be able to cancel it, or to skip and reboot right away....
I'm still not understanding the use case. And very highly likely a "me" problem. I have routines to check every 1 or 3 minutes or 5 minutes for important things to ensure they don't go out of sync/whack, e.g. does the HVAC system need to be on because a virtual thermostat is calling it, is it really on, or if it doesn't need to be is it responding and turning off. If the hub reboots, it's not going to check for that during downtime. How would a new shutdown notice work for me, since the check isn't going to run while the hub is off anyway and all devices can't be checked anyway?
Is this a use case just for Maker to turn off pistons from running? This is not a criticism of the request. I'm trying to understand and also bring up other related needs or requests.
I have routines to check every 1 or 3 minutes or 5 minutes for important things to ensure they don't go out of sync/whack, e.g. does the HVAC system need to be on because a virtual thermostat is calling it, is it really on, or if it doesn't need to be is it responding and turning off. If the hub reboots, it's not going to check for that during downtime. How would a new shutdown notice work for me, since the check isn't going to run while the hub is off anyway and all devices can't be checked anyway?