What you want to add is a Wait condition before your End-IF:
Wait for Kitchen Window Close or Not Family Room Heating
Restore: Kitchen Nook Dimmer
END-IF (Already there)
Then Remove the extra “If (Kitchen Window Open/Close Sensor closed)”
This however won’t capture the case where the window is already open and the heat kicks-in. For that, you will need to have two triggers: Kitchen Window Open and also Thermostat - Family Room Heating
Then in your if condition, make sure you have both the Thermostat AND the Window Open.
The captured state wasn't being collected properly, changing the driver for the dimmer from Generic Z-Wave Smart Dimmer to Generic Z-Wave Central Scene Dimmer fixed that.
In my original Action I have a "--> delayed: 0:00:05" thinking it would allow a contact sensor to be open/closed quickly without triggering the light flashing. This is not the case, playing with the "cancelable" variable had no effect either.
What do I need to add/change to allow this to happen?
If I go to a thermostat and raise the current temp setting so that it is heating, the light starts to flash, even though there is no open window.
Turning the light on/off at the dimmer switch had no effect on the flashing state. But, if I turn the light on or off from the devices page, the flashing stops.
The operation you describe matches what I see in the rule. It gets triggered when any of the operating states turn Heating, and the initial IF tests if any are heating, then flashes.
Why again are the operating states in the trigger? It seems that, if you remove that trigger, it would behave as you want. Trigger on window becoming open, capture state and flash if heating, wait on idle.
Actually, because of the enclosing IF on heating, seems like you could do the same thing, and clearer, if you eliminated the outermost IF block and moved the heating test into a predicate (and eliminated the heating trigger). That way, opening a window would only trigger the rule if you were heating.
Basically, all the triggers (opening of windows) are ignored when the Predicate is False (not heating).
Remember, Triggers are events, and it is the opening (not the fact of being open) that triggers the rule. Heating is a state. I believe that is what you are trying to do. If not, correct my understanding of your problem statement.
Now, as Sebastien notes, this doesn't handle a window being open and THEN the heating kicks in.
What is it you want the rule to do? Do you want to flash any time you simultaneously have heating and a window open? And, if that's the case, do you want to keep flashing as long as any window is open and any heater is going? If that's the case, then it's a different rule, and the triggers would be as before.
Please explain exactly when you want to start flashing and when you want to stop. Do you want to flash only if any window is open and any heater is going, otherwise don't flash? That would start flashing if a window was open and heating started, or would start flashing if heating was on and a window was opened, and would stop only when all windows were closed and no heaters were on. Is that, instead, what you want? If so, I could do a rule for that.
If the heat is already on, and I open a window, the lights flash.
However, it doesn't work the opposite way. If a window is open and the heat comes on, the light does not flash. And that is actually the more likely scenario I am trying to address.
As far as stopping the flashing.... it should keep flashing until the windows in question are closed. If the heat still needs to be on after the window is closed, I don't want to the lights to keep flashing.
You want to flash only if any window is opened and any heater is already going, or if any heater turns on and a window is already open.
That would start flashing if a window was already open and heating started, or would start flashing if heating was on and a window was opened, and would stop when all windows were closed, regardless of the state of heating.
Ok, I'll do a rule for that. Give me a few minutes.
Ok, try this. If it works, you will need a few lines in a systemStart Rule to handle the case of trigger events happening while your hub is shut down or rebooting. I will post that in a minute.
An aside: The rule statement you approved above matches the operation of this rule. However, I believe that you might want, if windows stay open, and heat comes on and then, later, goes idle, even if the windows are still open, for the flashing to stop. I will post that modification next.
Here is a discussion of how it works.
If a window opens, or if heating starts, the rule is triggered. The wait for condition will be cancelled every time the rule is re-triggered. For this reason, so that the state of the dimmer flashing doesn't get re-captured, the flashing variable tracks whether we are already flashing. The wait for condition won't fall through until all windows are closed.
I had a client call, had to handle that emergency.
Ok, here is a third version of the rule, different from the problem statement that you approved above. With this version, if, while flashing, all heating stops, then, regardless of whether windows are open, the flashing stops.
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:
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.