Is there an option to delay the fan from turning on once the humidity level is reached? This would be very helpful when the steam shower is being used, and having the steam sent straight out of the vent defeats that purpose.
I could trigger an external automation that would set the âdisable automation inputâ for a chunk of time. Though it would be a good solution to incorporate such a delay.
Could you try this and see if it works for you. I am guessing you are going to need it to run normally but when you have a steam shower you will need to do something to tell the automation you are having a steam shower. As a test before you go crazy and maybe use your voice to toggle the helper could you create a toggle helper and set up the bypass as shown below.
I created a toggle helper called âSteam Shower Toggle Helperâ. What will happen is when you turn ON the âSteam Shower Toggle Helperâ the fan will turn OFF. Then we enabled the bypass auto OFF and set the time for 15min. You donât need to do this you can manually turn OFF the âSteam Shower Toggle Helperâ if you like. If you do use the auto OFF it will then turn the âSteam Shower Toggle Helperâ OFF in 15min as per the setting.
Normally double click buttons have no state. So what we need to do is set it up so your double click action controls a toggle helper similar to turning on a light or a switch but use a toggle helper. You then use that toggle helper in the automation as the automation must see a state of ON / OFF and double click buttons normally donât provide that information to Home Assistant.
Right, and that makes total sense. The Bath fan disable when double click automation. is doing what you described. I didnât include this level of detail before. The MBSSB is a helper that goes into your blueprint instance. From there, I set the instance to auto turn off the helper after 15 minutes (I think that was in your original screenshot).
Collapsible Sections - Added collapsible sections to the blueprint. This enhancement improves the blueprint user interface by making it cleaner and more organized, allowing sections to be collapsed.
This feature was introduced in Home Assistant 2024.6, so you must have this version or later for the blueprint to work.
Maintenance
We have updated input descriptions to better help understand what they do.
Code Clean Up
Cleaned up code for reliability that could cause a bug.
If you like this blueprint? Consider hitting the button in the top post
If you like my blueprints, and would like to show your support or just say thank you? Click Here
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.
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.
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.
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.
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.
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.
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
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:
Switch tripping immediately preceded by an X% rise in the humidity derivative sensor value.
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)?
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.
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 ).
I am attaching the controller wiring diagram to complete it:
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):
Fan bathroom switch on, triggered by automation, Fan bathroom switch on, triggered by numeric state Derivative sensor bathroom
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 âŠ
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.
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âŠ
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.
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