Run exhaust fan from humidity, how to add manual option?

#1

1) Give a description of the problem
I have a piston that operates a bathroom exhaust fan when the humidity rises, and shuts off when the humidity drops. It works well. I’m trying to add an option that allows it to be turned on manually (switch or app) and shut off after 5 minutes. Can’t seem to add this without breaking the humidity functionality.

2) What is the expected behaviour?
Add option to have it shut off after X minutes regardless of humidity.

3) What is happening/not happening?
adding Else… If fan turned on wait X minutes breaks humidity functionality.

**4) Post a Green Snapshot of the piston![image|45x37])

Vent%20Fan%20Piston
Vent Fan Piston.png1178×732 66.5 KB

#2

when you start automating and adding manual into that the way I know is variables and simulated or real switches…
I have an AC piston and the house is around 77 BUT when maids are here I want them to have a cooler house than it is. wether the house 75 or 70 until they want it off…
So instead of changing number in webcore, I used a variable that if it’s FALSE the piston looks for AC low and high numbers, if the variable is TRUE it’s now all manual.

They have wall ipad and action tiles. All they need to do is push the button says AC ON MANUAL.
You can even use a smart zwave wall button or alexa etc… anything that can trigger a piston.

#3

You can add a boolean “manual override” variable as @ike2018 suggested, to block humidity controls but i wanted to clarify your intention:

If you setup a manual override variable, it can block the humidty controls for as long as the variable is in a specific state. But the moment you deactivate that variable, the humidity controls kick in. So if you turn off the switch after 5 minutes and deactivate the variable, the humidity control kicks in. If for some reason the humidity exceeded the upper threshold then the switch would turn back on again immediately.

This also presents another problem whereby the piston doesn’t know how the switch was turned on, manually or via automation, just that it is turned on. So humidity exceeds the threshold, turns on switch, piston sees turn on and proceed to activate the manual override block turning off in 5 minutes, then back to humidity control and the cycle would continue.

But I suppose you would never be turning the fan on if humidity was greater than the threshold as the fan would already be running?

#4

I would do something like this:

image
image.png1178×1049 49.2 KB

Notice I changed the conditions to triggers, i.e. humidity rises above instead of humidity is above.

#5

This is perfect… thank you for taking the time to write that out. The manual override variable is what was missing, and it makes sense to me know why the method I was using before was breaking the check for humidity. Thank you!

#6

Quick follow up question… I rewrote the piston exactly as you did, and it works just fine.

Sometimes the humidity will drop below the threshold and then quickly rise back up above it. I was trying to avoid the scenario of the fan shutting of and then turning right back on, so I added in a “Wait 5 minutes” right before the turn off command after it drops below the low threshold.

Again, this breaks the functionality and I don’t know why. It will drop below the threshold, start the timer, and then the next sensor reading resets the timer, and it never shuts off…

#7

Line 49 is a trigger… Meaning after the 5 minute WAIT, the trigger is no longer true. You can try setting TCP to Never on the WITH containing the WAIT. This will force the rest of the code to execute after the WAIT.

Of course, this means after the WAIT, the switch will turn off, regardless of the current humidity. You may have to also add a condition after the wait to check to see if the humidity is still below X.

Personally, the path I usually take is to space/spread the two {threshold} variables a bit. For humidity, if there is 10-15 unused numbers between {lowThreshold} and {highThreshold}, then it will not turn on and off so often. Also, with this method, the WAIT and TCP tweak is unnecessary…

#8

The simplest solution, as @wcmore pointed out, is to space out your thresholds. You could add a recheck condition but it gets messy. I like to keep things as simple and streamlined as possible.

Edit: That is also why I added the variables for thresholds, one edit and done. You don’t have to edit every trigger to change a value.