Ok. Here is how to handle events while rebooting and during hub shutdown. This is a matter of personal preference about which Bruce Ravenel and I disagree. I believe that a systemStart rule is needed to put all complex rules back into the correct state, automatically. Bruce seems to like going around and changing modes, etc., to get things into the correct state. I disagree. If I am not at home and a power fail occurs, my wife can't be bothered with setting modes and configuring complex rules and global (i.e., Hub) variables. Here is Bruce's comment a week or so back:
Anyway, to accomplish configuration of this I had to change the Local Variable in variant 3 of the rule to a Private Boolean so that it could be accessed from the System Start rule. No other changes were made. A similar change would have to be made for the other two variants. I used Private Boolean rather than a Hub (global) Variable to minimize namespace clash across rules. Private Boolean is a form of Local Variable. The Local Variable "Flashing" has been removed.
Here is the slightly modified rule, using Private Boolean:
And here are the lines that you would need to insert into your systemStart rule:
The Run Rule Actions effectively triggers the Thermostat rule, which self-initializes the flashing as if it were the first run-through.
Edit: Does that work for you? I think you might also need to add a Refresh on all of the contact sensors and possibly the Thermostats to get their state correct if there were changes during shutdown or rebooting. Remember, the Thermostats and Contact Sensors will be operating while the Hub is not (during rebooting and shutdown), so those events are missed. I don't have your devices to test. I do have to refresh my Ring Alarm Extender Gen 2 devices in my systemStart rule to account for the "switch to mains" event that happens during power restoration before the Hub boots, because those events were missed by the Hub.
