Help with Window Open and Thermostat On Rule

We have baseboard heaters, so I'll have to modify this rule to say if "any" thermostat is on, and this window is open... but for now.

I can't seem to get the flashing to stop. I also tried this using the Predicate Rule function, but that didn't work either.

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.

Makes sense?

Hot diggity! Thank you for your help.

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.

Here is what I have now:

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?

In order to have it only trigger when the window is open for 5 minutes, you will need to do a Wait for rule with a duration of 5 minutes.

(There’s a switch for that on the bottom when you select Wait for Rule.)

Interesting "bug" in the current Rule.

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.

Anyway to fix this?

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.

So do I just remove them as triggers from the Rule?

Yes, see my edit about taking out the outermost enclosing IF and making the heating trigger be a predicate.

1 Like

Any chance you could dummy up a sample? I'm still very, very new to this, and have no dev experience.

Give me a minute. I don’t type very fast, and I will have to make a few virtual devices.

2 Likes

See if this is not clearer.

We were all there once.

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.

1 Like

Ok, installed, and I'm testing it.

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.

Edit: Ok, my new understanding is:

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.

2 Likes

C'mon, c'mon, we're all waiting here!! :wink: :smiley: Slow typists are the worst! (I should know, I'm the slowiest.)

1 Like

Slow news day? :rofl:

1 Like

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.

1 Like

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.

systemStart rule follows to handle the case of events while hub rebooting or shut down.

1 Like

Very nice! I hear a lot of "oooing" and "ahhhing" from the stands. :smiley:

1 Like

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.

1 Like

If only I could bake bread as well as you can.

3 Likes