🚿 Bathroom Humidity Exhaust Fan

Blueprints Exchange
, , ,
478

Sorry for being a complete idiot here but can you explain a bit the purpose of the derivative sensor?

I’m trying to determine if this blueprint is for me.

I added a derivative sensor for one of my humidity sensors (master bedroom) just to test and see its behaviour. I noticed over night the humidity within the room crept up as we slept to almost 80% but the derivative sensor never crept over 0.4%.

I’m guessing the derivative is best served for a spike in humidity instead of a gradual increase? My worry is during a shower derivative kicks in the fan, lowers humidity and then turns off however the humidity then starts to gradually increase to a point the fan should kick in again but doesn’t because the derivative is too low.

479

That’s pretty much it. You simply adjust the off-delay to prevent the fan from turning off due to the decrease in humidity that it causes by being on.

1 Like
480

@GTunney

And this is why we use the derivative sensor so the fan only comes ON when is needed.

Yes, when you Have a shower you should see a spike. When finished you should see a drop spike. You then also have the option to use “Maximum Humidity” this will turn the fan ON but not OFF for when you have back to back showers. All this is explained in the FAQ Click Here.

Try it out and see it for yourself.

Blacky :smiley:

481

I shall give it a go but I don’t think it would be applicable in my scenario.

Ideally I’d like the fan to come on / off regardless of how quickly the humidity incremented so may be better off just using set values for humidity and triggering automations based on that.

482

The whole point of this blueprint using derivative is to prevent the fan coming on simply because it’s a humid day. Using set values of humidity only will likely end up causing the fan to come on at odd times due to the weather. ie: in the middle of the night when you don’t want it to.

1 Like
483

FAQ – Manual Trigger

This feature allows you to manually trigger the automation, replacing the humidity derivative settings in either ‘Default - Summer Mode’ or ‘Winter Mode’ configurations. Turning it ON initiates the automation process, and turning it OFF starts the time delay. Note that auto triggers can and will override the manual trigger option if activated.

This feature can operate with or without a humidity sensor, which is particularly useful if the humidity sensor malfunctions, allowing time for repairs and reducing stress levels. It is designed with good spouse approval in mind. It can also serve as the primary trigger for the automation if you don’t have a humidity sensor and cannot create a humidity derivative sensor.

Additionally, you can customize a manual trigger by creating any template sensor you can imagine. This is a powerful feature that allows you to trigger the automation in various ways.

You can use it with a physical switch on the wall that lets you trigger the automation to turn ON the fan before a shower, aiding in humidity removal before the auto triggers take over. This can be very useful in the colder winter months when humidity levels are high or during quick, colder showers in summer where a humidity derivative sensor may not trigger the automation.

How it works.

  • When you trigger the manual trigger, it will run the automation turning ON the fan, light and automation link.
  • It will then wait for the manual trigger to turn OFF by either manually turning it OFF or by the safe guard or auto OFF time delay.
  • Once turned OFF the automation will then proceed to the time delay in either ‘Default - Summer Mode’ or ‘Winter Mode’. It will then continue as per your settings you selected in ‘Default - Summer Mode’ or ‘Winter Mode’.

NOTE: The auto triggers can and will override the manual trigger option if activated at any point. Although this can be used as the main trigger it was designed to add value to the auto triggers.

Enjoy

Blacky :grinning:

Back to FAQ: Click Here

1 Like
484

After using this great blueprint now for several weeks, I understand things around the behavior of the humidity etc all a bit better and have my setup dialed in quite well where I am quite happy with it. I experimented a lot, and tried 3 different Humidity sensors until I landed on this one, and countless mounting positions thereof in the ensuite before I was happy with it all.
I thought to share my graphs showing the relationship between humidity, the derivative, and where the fan turns on and off. Since I used these graphs, it made it much easier for myself to understand the nuts and bolts behind it all. I hope this info might help others in turn.
Thank you again Blacky for this, and all your patience with my ‘not-so-smart’ questions at the beginning :slight_smile:

Screenshot 2024-06-19 at 18-59-07 History – Home Assistant
Screenshot 2024-06-19 at 18-59-07 History – Home Assistant1942×1711 304 KB

Screenshot 2024-06-19 at 19-08-08 Settings – Home Assistant
Screenshot 2024-06-19 at 19-08-08 Settings – Home Assistant2340×1509 311 KB

1 Like
485

Hello, Blacky,
I’ve successfully used your second blueprint, here’s my YAML for good measure:

alias: VentilĂĄtor koupelna
description: ""
use_blueprint:
  path: Blackshome/bathroom-humidity-exhaust-fan.yaml
  input:
    trigger: sensor.derivacni_senzor_koupelna
    fan_switch:
      entity_id: switch.vypinac_ventilator_prepinac_1
      area_id: koupelna
    time_out: 20
    include_manual_fan_switch: enable_manual_fan_switch_auto_off
    manual_fan_switch:
      - switch.vypinac_ventilator_prepinac_1
    rising_humidity: 0.7
    include_max_humidity: maximum_humidity_enabled
    max_humidity: 80
    bypass_auto_off_delay: 20

I have a question for you about the “manual_fan_switch” function. I tried to enable it, although I didn’t have much hope that it would work. Namely: you write that the manual switch must be independent. My fan switch is a classic mechanical switch on the wall, with a wifi controller between it and the fan (only one switch is connected). Ultimately, therefore, the fan is always switched by this controller - whether it has been switched on by the mechanical switch, or by an instruction by way of wifi (and therefore automation). The situation can be clearly seen in the definitions of “fan_switch” and “manual_fan_switch” above. This explains the fact that “bypass_auto_off_delay” doesn’t work. Do you think my explanation is correct?
If so: I understand that the automation does not know if the switch was turned on by a human, or by the automation. However: Couldn’t some counter be used to track these states:

  1. Switch tripping immediately preceded by an X% rise in the humidity derivative sensor value.
  2. the switch trip was not preceded by a rise in the value of the humidity derivative sensor (and therefore was manually tripped - if this option is enabled)?

Thanks for the answer!

486

@vaclavIII

Yes you can’t use the same switch that controls the fan and the manual fan switch.

Looks like you have a smart plug for the fan and a wifi switch to turn ON the smart plug. If so detach the wifi switch from the smart plug. Then use the smart plug in the automation for the fan and use the wifi switch for your manual control.

Blacky :smiley:

487

Thanks for the quick reply!
No, it is not a smart plug, it is a wifi module (controller) under the switch in the wall, the fan is also built into the wall. I don’t want to disconnect it (already because it was very difficult to put all the wires plus the controller into the switch box :slight_smile: ).
I am attaching the controller wiring diagram to complete it:
Controler

I also found that the automation knows how the switch (controller) was turned on/off. I attach a screenshot of the history of the entity “fan bathroom switch” in HA, (I am translating from Czech):

History
History750×1334 148 KB

  1. Fan bathroom switch on, triggered by automation, Fan bathroom switch on, triggered by numeric state Derivative sensor bathroom
  2. Fan bathroom switch, off
    (State 2 is triggered by the manual switch (and interpreted by the controller)).

Thus, it would probably be possible to build this algorithm into your automation:
If the fan is controlled by a controller that allows bypass for a mechanical switch, take into account how the fan was turned on - whether by automation or manually. In case of manual switching, enable “manual_fan_switch” and also “bypass_auto_off_delay”. I don’t know how though - I’ll leave that to an expert :slight_smile: 


488

@vaclavIII

I see in your electrical wiring you have crossed off one switch with a L2. Not sure if it is there but if you get an electrical contractor to add a switch on S2 and just use the switch not L2 as an input then you could use that.

Blacky :smiley:

489

Sure, I only used switch No 1 on the controller, and that’s because I didn’t have a module with a single switch (the module is adapted for a mechanical double switch). Switch 2 is not used, the fan is controlled purely by switch 1.
Adding another mechanical switch is not possible for space reasons. Is it really not possible to solve the situation with automation? I have a similar module for controlling lights, where I want to use your blueprints for common control of entities, while fully preserving the function of the mechanical switch. There I may run into the same problem


490

I have looked at this in the past but I will put it on the list to revisit it. I have a new version currently undergoing live testing so I may have to hold this release back.

Blacky :smiley:

491

Sounds interesting, thank you Blacky! I would also be keen to follow this. My setup looks similar to that of vaclavIII where the original wall switches still control the fan and light through the ZB T2 dual relay module, but I’m currently unsure how to use that in your blueprint and have not yet started to experiment with that whilst i was dialing in the fan / humidity part.
Happy to be a tester if you need one :wink:

Screenshot 2024-06-21 at 11-12-03 en-user-manual-20230608094029.pdf
Screenshot 2024-06-21 at 11-12-03 en-user-manual-20230608094029.pdf1660×1288 130 KB

492

Hello Blacky (and Vicusj),
I look forward to seeing your new version of the blueprint. I still tried to work around the independent triggering problem by introducing a “helper” so that the automation thinks that the manual triggering is a different switch, but I failed (I honestly didn’t have much hope
). I think the problem I described is fairly general - it’s nice to be able to control switches both by automation and manually - relatively independently.
Thanks to both of you for your comments!

1 Like
493

Just to add into this to show there is demand, I can also operate my fan via the original wall switch but also control it’s status via a smart relay.

494

@vaclavIII @vicusj @GTunney

I have looked into it again. It is a little bit tricky in the one automation but I have come up with a solution that could work. Below this post I am going to post a FAQ on how to make your actual fan switch control the fan manually in ‘Manual Fan Switch’ or the ‘Bypass’. Try it out and let me know how you go.

Stay tuned as I will do the FAQ now.

Blacky :smiley:

495

That’s great! I’ll definitely check it out, I’ll let you know. Thanks!

1 Like
496

FAQ - How to use the same ‘Fan Switch’ also in ‘Manual Trigger’ or ‘Manual Fan Switch’

If your wall-mounted physical switch controls the fan and you want to use this same switch to control the ‘Manual Trigger’ or ‘Manual Fan Switch’ functionality while ensuring your automations continue to work, you must create a trigger-based template binary sensor.

Please follow these steps

Step 1: Create a template binary sensor by adding the code below into your “configuration.yaml” file.

The things you will need to change are:

  • switch.your_fan_switch_id_here = Replace this with the entity ID of your fan switch used in ‘Fan Switch’.

The things you can change to your liking are:

  • Manual Fan Switch = This is the name you would like to call your new binary sensor.
  • fan-clock = The icon used. You can change it to your preference or remove the line icon: mdi:fan-clock if you don’t want an icon. To see what icons you can use click here.
template:
  - trigger:
      - platform: state
        entity_id: switch.your_fan_switch_id_here
        to: "on"
        id: "t1"
      - platform: state
        entity_id: switch.your_fan_switch_id_here
        to: "off"

    binary_sensor:
      - name: "Manual Fan Switch"
        icon: mdi:fan-clock
        state: >
          {% if trigger.id == 't1' and trigger.to_state.context.parent_id is none %}
            on
          {% else %}
            off
          {% endif %}

Step 2: Once you have added it into your “configuration.yaml” file, for it to take effect you have 2 options.

  1. Go into developer tools / under ‘YAML configuration reloading’, click ‘Template Entities’ (recommended).
  • OR
  1. Restart Home Assistant.

Step 3: You can only add it into either the ‘Manual Trigger’ or ‘Manual Fan Switch’. You can not add it into both choose only one.

OR

Step 4: Your done :partying_face: test it out.

Enjoy

Blacky :grinning:

Back to FAQ: Click Here

1 Like
497

Thank you, I’ve now added this and will test over the next few days.

How will this work if the fan Is manually switched on and then the humidity spikes after being turned on manually. Will the automation run or will the manual switch auto off time be used?