Simple Humidity Script Only Works in Test Mode



This is my second script and it seems to work only in Test mode. It seems simple enough but after two hours of trying to figure this out, I’m asking for help.

I’m trying to create a loop where the humidity on a sensor is checked and if above 75%, then an exhaust fan is turned on for ten minutes.

If there is a better was to structure this, I’m all ears. Thanks.



In your piston, notice the lightning bolt in the left margin next to “Sensor 6’s humidity”. This means the only time the piston will execute is when the device reports a change in the humidity. At that point, the piston will run top to bottom.

That being said, the general structure of a piston is usually something like this:

IF X happens
    Do Y

(notice I did not use “WHEN TRUE” or “WHEN FALSE”)

To help with the extra clutter, I recommend programming with only two check-marks in the Options:


I would uncheck all of the rest.
99% of pistons do not need them, and they tend to confuse more than help…

Here is a double block piston that may do what you wish:

IF Sensor 6's humidity RISES ABOVE 75
    Turn on Exhaust fan

IF Sensor 6's humidity DROPS BELOW 70
    Turn off Exhaust fan

(notice I left a gap between the two numbers!)

Alternatively, if you would rather the shutoff be time based, this single block works:

IF Sensor 6's humidity RISES ABOVE 75
Then with Exhaust Fan (TCP set to Never)
    Turn on
    Wait 10 minutes
    Turn off

This one turns off 10 minutes later, regardless of the current humidity.


While reading this, I was just thinking there should be a small gap between the two settings for the transition between the two temperatures.


I don’t want it too small because then the fan will cycle more often.

The ideal situation would be for me to build a PID control loop around this. I know the math but I’m not sure I can code it in this environment.


YES! :+1:

If this were my project, I would drop the “time based” logic, and let it turn on or off based on humidity.
(my first example above)

By playing around with the gap (either a bit smaller or larger), you will effectively ensure that it stays on long enough, without all the extra needless toggling back and forth.

Although, I should emphasize to not bring the two numbers too close to each other…

Just my two cents.

Side Note:

Nearly all math can be incorporated into any piston, but I generally discourage looping devices whenever possible.


One issue you will find is that most battery powered humidity sensors only take readings every few minutes to preserve the battery life. The humidity sensor I have in my bathroom will only take readings every 3 minutes, which is good enough for us.

I have seen scripts that attempt to get around this latency by taking averages of humidity and then if the humidity is higher than the average and higher than the last reading, it is determined that humidity level is trending upward, so the fan is turned on. This seems a little complicated to me. The double block piston with setpoints to turn fan on and off that @WCmore suggests above works for me, but I do find that I have to adjust the 2 setpoints with the change in seasons from summer to winter. No big deal.


If you are already familiar with your preferred high/low in the Summer vs Winter, we could probably whip up a math formula for you so it automatically calculates the offset on any given day.


Cool… Not sure if I remember what the preferred winter setpoints were…I will need to document it. Thank you!


Sure thing. Just tag my name whenever you have that information. :sunglasses:


So, I just noticed the exhaust fan was off (very recently turned off) yet the humidity was still above the lower limit. Being new to webcore I did the only thing I knew to do which was to pause and restart the script. That doesn’t result in the fan being turned on. So, I guess I don’t really know the mechanics behind the “rises above” trigger?

Any thoughts on this?

BTW, I did NOT add any time-based code, I used the first example.


Normally, “RISES ABOVE” only fires at the moment it goes from a lower number to something above that number.

Likewise, “DROPS BELOW” only fires at the moment it goes from a higher number to something below that number.

Another way to say this… If your two triggers are:
► Rises above 75… and
► Drops below 70
Then no commands will be sent from 70 - 75. (this is intentional)

So, for example, if it is currently 73, then the fan might be either on or off…
(depending on whether the humidity is rising or dropping)

If the fan is off at 73, this is normal. If it rises to 75.1 or above, the fan kicks on, and stays on until it drops to 69.9 or below.

If the fan is on at 73, this is also normal. If it drops to 69.9 or below, the fan turns off, and stays off until it rises to 75.1 or above.

You can turn your Log Level to Full to see a bit more what is happening behind the scenes…


I guess I am going to have to start trying to log. Yesterday afternoon the humidity reached a low of only 58% and sometime after that the fan shut off (which I didn’t catch). The humidity spiked to close to 90% today and the fan never turned back on.

Something is fundamentally wrong. I will post the current script.



Your piston looks good. Please turn log level to full, and paste it here the next time there is an issue.

Also, I would not edit the piston for a few days. We need to see it drop and then rise for the trigger to work. (meaning if you edit the numbers in the process, the triggers may not fire until next cycle)