I am realy not trying to go down this line as I had this before and the fan would turn on at night when everyone sleeping having a false trigger. I have thought about incorporating it but it hasn’t come to me yet.
I think it is all about what sensor and sensor position. As you can see what happens to me in the above graph.
Battery… it is easy and I have heaps of Bluetooth ones that work well around the house but I am using a;
Connected to ESPHome. It is all in the ceiling and the sensor is in the inlet grille. I have even painted it black so you can see it. Then because it is ESPHome I have full control. If in time it stops I have spare ones but I haven’t had to do that yet. The ESP32 also controls my bathroom motion sensor that control lights and LED strips. The motion sensor is hidden under the vanity so you can’t see any tech.
EDIT: It seams strange as I was looking at your graph in more detail. It looks like you have gone from 70% to 90% and your derivative only went to 2%. If you look at mine I went from around 75% to 84% and that gave me derivative of 3%, then it went to 95% and my derivative was 7% but you only got 2%. Must be sensor and the settings of everything. I have checked the FAQ and my settings shared are correct.
I thought I would share 2 more shower data from today. The fan was turn ON manually before the shower with a delay time of 8 min as it is winter here . You can see the automation run as expected and is typical of a normal automation trigger if the fan was not turned ON manually.
I changed it to 6 minutes but don’t have enough data to make a determination yet.
I had an idea though. Do you have it setup to end and move to the final run time when it goes below the negative value or above?
If you have it set when it goes below the negative value, wouldn’t it make more sense to wait until it rises back above it going the other way? Then the clearance or end run time wouldn’t need to be much, if anything.
Maybe you already have it that way but it wasn’t clear to me from the documentation.
The way it work is, we receive a trigger when it goes above the “Rising Humidity” and turns the fan ON. It will then wait until it then goes below your “Falling Humidity”, but it will only wait for as long as your “Safe Guard - Maximum Run Time” setting. When this happens it then moves to the “Time Delay”, once that is completed it turns the fan OFF.
Have you considered waiting until it goes ABOVE the Falling Humidity parameter? That would run the fan longer based on the actual humidity and not require as long of a fixed time at the end. To go above, it must cross from below so you know the value will be below the Falling Humidity number before it will trigger.
It would just better account for varying amounts of time in how long it takes for the humidity to drop.
Is there a way to make a change to a blueprint like yours myself and test it out? I’m newish to HA and couldn’t find that when I looked.
Thanks for that sensor. I’ll check it out. I’d have to make sure I could get Bluetooth working on my HAOS box. Haven’t looked at that yet.
It starting to look better and you could probably work with that. So now just play with your delay time … it looks like the fan had a short delay time. What are your setting on your Derivative Sensor now as a matter of interest?
Yeah, I think once you upgrade your sensor so your not reading every 5 min but every 60 sec or every change then you will find it will work a lot better. For around $10 to $15 US dollars I think it is money well spent and will save you a lot of time.
Did you change any settings on your Derivative Sensor?
Yes you can have Fahrenheit on the sensor and in HA
Edit: If you get some I would say get 5 + you will use them. I have one in my fridge, outside, kitchen, family room, bedrooms, laundry, etc. Once you get them it is nice to have. My battery’s lasted over a year. My Atom Lite (ESP32) that runs my humidity sensor for the exhaust fan is also a Bluetooth hub thanks to HA that they connect to.
A lot that has been added to this new release. Hope you like it.
Added a selection option to use the “Fan Speed - Switch Off Option”. Note: If you are using “Fan Speed - Off Switch Option” then you must now select to enable this option for it to work. It is the same function as before just the description has change and you must now enable it.
Added options for lights. If you have selected to use lights before in “Fan Switch” and they are a light entity then you will have more options for lights. It is recommended to remove them from “Fan Switch” input and add them now to the light options. If you have lights that are a “switch” entity then just add/keep your switch entities for your lights in “Fan Switch”.
Just found out about this blueprint, and figured someone might benefit from my two cents which solves the needing different seasonal baselines as well as potential false positives from organic large changes in humidity. Apologies if this has been covered before - I tried to read through the thread but I may have missed something skimming.
Because I have many humidity sensors (every motion sensor and every thermostat) I have a pretty good representation of the median humidity across my house. This gives me an excellent baseline to know when humidity for one bathroom differs significantly from the rest of the house. I created a helper sensor for the median humidity, and then derivative sensors for both the median humidity and bathroom humidity sensors. I then used these to create template sensors to calculate the difference between the derivative of humidity for a given bathroom vs. the median humidity overall. If this delta is positive of a certain magnitude for a certain period of time, I turn on the fan. If this delta is close enough to 0 for a certain period of time, I turn the fan off.
Here’s an example config for the delta template sensor:
Hey @Blacky. I have just installed this blueprint (after taking an obligatory shower to start recording derivative stat patterns). I have also seen (and imported but not yet setup) the Temp Control Exhaust Fan and Toilet Control Exhaust Fan. Do all 3 of these automations conflict with each other if you try and run them for 1 room? I currently have a NR workflow setup but it is pretty complex (and doesn’t do temp control) and it would be nice to move over to automations like the amazing work you have created in all 3 of these.
My own environment setup is an ensuite bathroom, with shower, toilet and sink. The exhaust fan was a continuous running fan that was controlled by light switch (ensuite light off and the fan would run in lower power mode, turn the light on and it would run high power mode). About a year ago I added a Shelly 2.1 into the mix and an Aqara humidity sensor. I can now control each of the high and low speed fan as and when I want rather than it running all the time which means night time no fans run anymore unless someone either uses the toilet or shower and even then, once humidity/time is down to a level I want the fans turn off.
Also, would the ‘Humidity Derivative Sensor By-pass’ be something like an automation enable/disable switch/input_boolean? The FAQ shows a question on how to set this up but no answer. I am guessing it is for overriding the automation - eg each and every automation I have in the house can be overridden with an input_boolean for the given task such as don’t turn the lights on for a given room when it is dark
@Blacky thank you for the answer. I will configure the other 2 for now and see how it all interacts.
The bigger roadmap sounds very interesting though
Thanks for the tip regarding the lights however I don’t have control over those for the ensuite and they are dumb lights. The Shelly only controls the fan based on a seperate feed from the light switch which is what used to make the fan high power or low power depending on current.
EDIT: DOH! My mistake, I see what you mean about the light automation. Might be of use elsewhere around the house as long as I can work in the house modes into the automation ( I run house modes of away, night, evening, midweek, morning midweek, weekend, morning weekend)