Bathroom ventilation stops too early

Hey guys,

sorry to disturb you again… but maybe it’s just to late to my head isn’t awake enough to find the solution for my problem on my own… I bet it’s very easy.

I have a ventilation system in my bathroom and a sensor for humidity. If the humidity becomes higher as 80 I want to ventiatlation to start for 45 minutes.

Start of the rule is working fine humidity becomes 80 the ventilation starts… but it stops as soon as humidty is lower as 80. I think I already now why … because my rule works on “> 80” so it stops if “< 80” is reached. So it only should react on the change >80 but after that it can ignore the humidtiy and should only react again when it changes to >80 again…

But at the late hour (in germany) I don’t find a solution how to do so.

rule "Entfeuchtung Gästebad"
    Item EG_GaesteBad_Luftfeuchtigkeit changed
    if (EG_GaesteBad_Luftfeuchtigkeit.state > 80){
    sendCommand(EG_GaesteBad_Lueftung, ON)}
    createTimer(now.plusMinutes(7)) [|
    sendCommand(EG_GaesteBad_Lueftung, OFF)

Any idea?

I usually use virtual switches and the expire binding instead of timers. I understand timers tie up rules threads and there are only a total of 5 threads.

1 Like

Are you sure that is why it is stoppiing?
As it stands, every time your humidity changes he rule wiil run and if >80 create a new timer for 80 minutes ahead.
Depending on how often your humidity updates, you could have dozens of timers at different stages, all poised to turn off the fan again and again.


As @rossko57 said, you might be kicking off several timers for any change which is still above 80%. Why don’t you just turn the fan on and only turn it off when the humidity has reached a value below 80% - or additionally after a certain longer time period to avoid the fan running constantly in humid conditions.

You might also want to think about lowering the humidity threshold as humidity above 60% over a longer period of time will encourage mould.

You say 45 minutes, but your timer is set for 7 minutes…

Your rule as defined above will not result in this behavior.

You want to declare a variable outside the body of the rule to hold a reference to the Timer (e.g. var Timer fanOffTimer). That way you can check to see if the timer is already running, in which case you won’t start another one. That will resolve the problem of creating a timer every time your humidity changes and its above 80%. There are plenty of examples here on the forum about how to do this.

Incorrect. Thread::sleep ties up a thread. A Timer recedes to the background and does not consume any threads until it’s actively running.


Install Expire Binding

Change Item EG_GaesteBad_Lueftung like example

Switch EggCooker "Egg Cooker [%s]" { zwave="12", expire="45m,command=OFF" }

Remove from rule

    createTimer(now.plusMinutes(7)) [|
    sendCommand(EG_GaesteBad_Lueftung, OFF)

Hi all,

thanks for the feedback. Currently I’m at work… so will try some things in the evening.

I want to give feedback on two points.
7 Minutes instead auf 45 - Yes thats correct. For final use I want to work with 45 for testing I work with a smaller time to see the result earlier. So will change this to 45 later.

And regarding 80% humidity. I want the ventilation to start when I take a shower so humidtiy goes on a very high level. The trigger works fine but the problem with the sensor is that even after 5 minutes the humidity at the sensor is down to 60% or 50% even if the room is still very wet. To have a work a round for the sensor I want to use the humidtiy as a trigger and do the ventilation based on a time long enough to get the room “dry” again which is done after 45 minutes (for a 5 minute shower and also for a 20 minutes shower).

What you almost certainly need is a way to make only one timer at a time.

That makes dealing with multiple triggers easy - you look to see if the timer already exists before creating a new one. If it does, you can choose to let it run or optional reschedule it to extend it.

The secret is to put a “handle” to your timer into a global variable so that your rule can test what it’s up to.
There are numerous examples of this kind of thing - a popular starting
" Simple Example: Timers Version "

@c0rtez @denominator provided the most straightforward solution above. This is the simplest solution, and it doesn’t involve the use of timers at all.

1 Like

I don’t see why this wouldn’t work as a state machine (no timer needed)…

  • If humidity >80 and fan is OFF, then turn fan ON and set variable with current time
  • If humidity <50 and fan ON and current time is 45 minutes after variable, then turn fan OFF

The time variable is not needed if you use persistence. Are the humidity readings polled (time based), or are they reported based on a percentage change?

1 Like

I tried the solution with expire binding… but it didnt worked.
I installed expire binding… for me it looked like nothing is needed to configure


Switch          EG_GaesteBad_Lueftung       "Lüftung"          <fan_ceiling>        (EG_GaesteBad, gFan)            ["Switchable"]               {channel="knx:device:bridge:generic:EG_GaesteBad_Lueftung", expire="7m,command=OFF"}

The rule

rule "Entfeuchtung Gästebad"


    Item EG_GaesteBad_Luftfeuchtigkeit changed


    if (EG_GaesteBad_Luftfeuchtigkeit.state > 80){

    sendCommand(EG_GaesteBad_Lueftung, ON)}


Resulst is the same as before.

To verify your expire binding install, try it out on an Item linked to nothing else.

Please be explicit. Maybe show events.log demonstrating what happens.

How often does your Item get updated from KNX? Every state update restarts the expire timer.
How often does your humidity change? Every time the rule runs and issues another ON, it restarts the expire timer.

1 Like

Need to check the expire binding in the evening.

Regarding update period. Humidity state gets send everytime it changes. Which happens very often when showering and ventilating afterwords.

But the fan doesn’t even run for the mintues I added to the timer / expire binding. For testing I work with 7 minutes. If the problems comes from a reststart of the timer over and over… shouldn’t the result be that the ventilation doesn’t stop? It stops already after some minutes / seconds.

That’s why I asked for more detail.
How about those events.log entries? At the moment, we don’t know if the unexpected OFF originates in openHAB at all.



Sorry for coming back to this late. Unfortunately some other things took my time for going on with this.
But I continued today:

So my current rule looks like this:

rule "Entfeuchtung Gästebad"
    Item EG_GaesteBad_Luftfeuchtigkeit changed
    if (EG_GaesteBad_Lueftung.state == OFF && EG_GaesteBad_Luftfeuchtigkeit.state > 80){
    sendCommand(EG_GaesteBad_Lueftung, ON)}

Items - EG_Gaestebad_Luftfeuchtigkeit & EG_GaesteBad_Lueftung

Number          EG_GaesteBad_Luftfeuchtigkeit "Luftfeuchtigkeit" <humidity>         (EG_GaesteBad, gHumidity)       ["Humidity"]                 {channel="knx:device:bridge:generic:EG_GaesteBad_Luftfeuchtigkeit"}
Switch          EG_GaesteBad_Lueftung       "Lüftung"          <fan_ceiling>        (EG_GaesteBad, gFan)            ["Switchable"]               {channel="knx:device:bridge:generic:EG_GaesteBad_Lueftung", expire="7m,command=OFF"}
2020-02-06 21:35:36.604 [vent.ItemStateChangedEvent] - EG_GaesteBad_Luftfeuchtigkeit changed from 36.5 to 36.4

2020-02-06 21:35:46.605 [GroupItemStateChangedEvent] - gHumidity changed from 62.67 to 67.12 through EG_GaesteBad_Luftfeuchtigkeit
2020-02-06 21:35:46.614 [vent.ItemStateChangedEvent] - EG_GaesteBad_Luftfeuchtigkeit changed from 36.4 to 54.2
2020-02-06 21:35:51.588 [vent.ItemStateChangedEvent] - EG_GaesteBad_Lueftung changed from OFF to ON
2020-02-06 21:35:56.596 [vent.ItemStateChangedEvent] - EG_GaesteBad_Luftfeuchtigkeit changed from 54.2 to 89.12
2020-02-06 21:35:56.604 [GroupItemStateChangedEvent] - gHumidity changed from 67.12 to 75.85 through EG_GaesteBad_Luftfeuchtigkeit
2020-02-06 21:36:06.605 [GroupItemStateChangedEvent] - gHumidity changed from 75.85 to 78.57 through EG_GaesteBad_Luftfeuchtigkeit
2020-02-06 21:36:06.610 [vent.ItemStateChangedEvent] - EG_GaesteBad_Luftfeuchtigkeit changed from 89.12 to 100.0
2020-02-06 21:36:07.593 [GroupItemStateChangedEvent] - gHumidity changed from 78.57 to 78.59 through OG_Bad_Luftfeuchtigkeit

2020-02-06 21:36:37.587 [vent.ItemStateChangedEvent] - OG_Bad_Luftfeuchtigkeit changed from 81.0 to 81.60000000000001

2020-02-06 21:36:42.591 [vent.ItemStateChangedEvent] - EG_GaesteBad_Lueftung changed from ON to OFF

Because of expire binding use on the ventilation for normal it should have stopped 7 minutes after activatino…but log says that the ventilation was deactivated not even a minute after it was activated… I have not idea why.

Only if you stop sending it ON commands. Every time you command ON, the 7 minute expire timer starts again.

Every time EG_GaesteBad_Luftfeuchtigkeit changes, if it is still above 80 another ON command is sent.
I’d expect the fan to stay running until humidity drops below 80, then run on for seven minutes more.

But im not sending another ON. Therefore I added a check if the ventialation is already running in the „if“ part. So ventilation has to be off and a Change higher as 80 has to happen.

And if Sending on would be a problem shouldnt be the result that it runs longer? But it went off after not even one minute

How does your KNX work? If that periodically updates as ON during use, it will again restart expire timer. Updates to same value do not appear in events.log, the easiest diagnostic for that is to have a simple rule triggered by update and have it give you a logInfo().

Looking at it again, your log excerpt does not show any commands at all.
Apparently,it was not your rule that turned the fan ON to begin with.
And does not appear to be expire that turned it OFF.
You might find expire’s command later, minutes after the fan mysteriously turned off.
EDIT - no, that won’t happen, if something else has set it to OFF then expire won’t issue the OFF command.

Or is this excerpt not complete?

Is your rule file being loaded? (check openhab.log)
If not, you might have old versions running. But as I say, at the moment there is no evidence any OH rule is controlling the fan at all.

Ok got it. and I may already know what the problem is. I tried doing something similar in ets. I deleted it but maybe i made a mistake there. Will check that

1 Like