Im in the process of installing a QuietCool whole house fan. Initially I had considered deploying a Zooz ZEN 17 (?) for complete control of the fan, however I suspect that the WAF for this scenario is low, so what I'd like to do is the following:
- Connect the fan with a Zooz Zen15 for voltage sensing.
- Configure RM so that when the fan mode changes to ON, i turn off both my Ecobee thermostats
- When the fan mode changes to OFF, I wait X amount of time before turning the AC back on.
What I am wondering about is X above. I want to make sure that nobody just plays with the button, toggling it on and off, and wreaking havoc with the AC, so I'd prefer to add a delay so that it will wait for it to change to off and remain in that state for 5 minutes before resuming AC cooling.
My question is this... when I setup the delay, is it as simple as just checking the Delay option and entering the value (eg. 5)? Or do I need to do something else to ensure that it doesnt run, if it's been less than 5 minutes and someone turns it back on?
I've seen some examples here about Delay Cancellable, is that what this is? And if so, do I need to add a Cancel delay for the ON condition, so it doesnt stack up a bunch of delayed actions?
Thanks in advance.
PS. Once I understand this I'll likely want to add contact sensors on a few windows, so they have to show open before ON actually does anything, but I suspect thats when I'll have to remove the QuietCool wireless switch and move to a ZWave switch and add more logic.
Here is what I would do:
Trigger: Fan mode becomes on
Actions to run:
Off: AC
Wait for event: Fan mode becomes off
Wait for event: elapsed time --> 0:05:00
On: AC
Actually, given what it sounds like you're doing with the fan, you may need a "power" trigger and wait instead of a "switch"-based one, but the idea would be similar. Perhaps you also want to add a "Wait for event: elapsed time" to the beginning of these actions to allow a sort of grace period there, too (I only did it before "on" since that is all that was mentioned).
But if you want to understand the behavior of delays, that's good to know, too! I think the above is easier in many cases, but this paradigm wasn't as popular in the early days of Rule 4.x, so you don't see as many examples with it. A delay does not get cancelled if a rule re-triggers (unlike a wait); the schedule it creates remains unless you remove it somehow, generally by marking it as "cancelable" and using a "Cancel Delayed Actions" somewhere in the rule, generally towards the begining of your actions or in the other half of an IF THEN/ELSE compared to the delay. So if you really wanted to, you could also write it like this:
Trigger: Fan mode *changes*
Actions to run:
IF (Fan mode is on) THEN
Cancel Delayed Actions
Off: AC
ELSE
Delay 0:05:00 (cancelable)
On: AC
END-IF
You could actually combine these two approaches and use a "Wait for event: elapsed time" instead of the delay and then forget about the cancellation; I'm really combining two simplifications into one above with the first rule, the other issue being the specific trigger versus a general trigger plus a conditional to check what it was (why do that when you can trigger on the specific event, not need to check it, then create a subscription on-the-fly--with that first "wait"--when needed?).
1 Like
So is it safe to say that the cancel only applies to delayed actions in the same rule? So if I had other rules running with delays, the cancel delay in Rule X wouldn't cancel a delay currently running in Rule Y? ie. the delays and cancels are scoped and not global...
When you say power trigger, I assume you mean create a virtual switch called Attic Fan that would be set either ON or OFF based on the rule for the Zooz Zen 15 when it detects power on / off?
Correct, "Cancel Delayed Actions" applies only to the rule in which this action is run. (If it matters, you can actually cancel delays--cancelable or not--from another rule if you need to: "Cancel Rule Timers" will do that, plus a bit more, and it lets you choose the rule[s] to apply it on.)
I wasn't actually thinking that, but I do think that is a good idea: it gives you an easier way to see what state you assume the fan to be in, and it simplifies the triggers and waits in this rule (it wouldn't be too hard to write anothe rule that manipulates this switch accordingly).
I was thinking more like doing that all in this rule, using a trigger that is something like "power is > 50 W" (or whatever value you need) and a wait for "power < 5 W" (or, again, whatever you need) instead of some switch/virtual device state. But either way should work!
2 Likes
Thank you, that helps tremendously. I hadn't had a chance to test delays yet, plus I think your example above will work really well.
Fan shows up Friday, I'm going to try to get it installed and the Zooz connected this weekend.
So my last question, regarding window sensor requirement for the fan to be allowed to run. Would it make sense to create a virtual device that is a combination of the 8 windows to set a ON \ OFF status I could use to permit the fan to turn on?
Ie. can I basically have a rule that says if 4 of the 8 windows are open, then set virtual device "Airflow" to ON, and when that device is on and the switch is pressed, allow the fan to turn on?
or have I veered into Zooz ZEN 17 territory? I'd like to be able to let the included QuietCool button work, but only if the windows are open, otherwise pressing it does nothing. (I dont have Alexa setup, so I can't have her complain about windows, but I could text pushover or hubitat notify)
That may be easier than using 8 devices separately in the rule (especially if you end up referencing them in multiple places or need to swap devices out), so I don't think it's a bad idea! There are some community apps that can "combine" these into one virtual sensor, or it would also be pretty easy to do with a rule (either a virtual sensor or virtual switch device would both work; you'd need custom commands for the former, but it's not much harder than "standard" rule actions). You could use them directly, too; I'd say it's a matter or preference.
