I understood the Sample duration is just used for cleaning up old samples. Sample values older than 2hrs will be deleted. I was hoping that I could still access the value from old samples (2 hrs ago) to see if the current humidity was close to the starting point. However, I was unsuccessful, I never changed it to something else. I started to store it in a variable/MQTT when the shower session starts.
With the trend sensor I was able to see when and how long my daughter’s shower session was, and I was able to store the starting humidity in a variable and a MQTT topic (I am testing both to see what I like best)
Your humidity stable comment made me have an idea though, just thinking aloud here…
“What if a trend sensor looks for a min_gradient of a low number (maybe -0.0001?) when It turns off, it is stable after a downtrend… when on, Humidity is still decreasing…and kind of removes the need for a timer and starting value…”
Again, I am in the same process as you figuring out how I can replace my first domoticz script in HA. I am open to suggestions
Ok, we have the same understanding on Sample_duration then ;). Storing values in variables is the ‘Domitcz’ way (which really worked well for me). However would be nice to have a solid alternative in HASS as well.
Humidity stable is actually tricky and I guess you need to use two sensors to determine whether the current humidity change range is within upper and lower limits. Alternatively monitoring whether the Humidity decline rate is below some threshold should be working just fine (this also compensates for temperature changes and hence potential different humidity targets).
Note that in your example you are not specifying the max_samples (default is 2). This might not be sufficient to get a reliable trend and will definitely result in not storing samples up to 2 hours back.
I don’t understand why you use variables ?
The point in the trend sensor is to detect increase (or decrease with proper option) of an entity value. If detected, it turns true. This can trigger an automation. In which you can use the entity value as a condition if you want to turn on the vent only if humidity is above X% ?
Example :
This is part of the house vent automation. I’ve kept the part where it starts when windows are closed, or when the trend sensors for bathroom and kitchen. In the conditions, it will start only it it’s off for a while (5mn), if windows are closed and depending on relative internal humidity (compared to external provided by weather component). Those are the templates conditions.
It’s all on the fly, I don’t keep any previous status.
The trend sensor are defined like this :
shower:
# On if +7%/minute
entity_id: sensor.humidity_158d000227327d
sample_duration: 600
min_gradient: 0.06
device_class: moving
#max_samples: 3
cooking:
# On if +5%/minute
entity_id: sensor.humidity_158d00022880d3
sample_duration: 600
min_gradient: 0.02
device_class: moving
#max_samples: 3
I seem to have difficulties in understanding the trend sensor. Why does a gradient to 0.006 result in a +7% per minute? I somehow got the impression that my trend sensor is not polling the humidity sensor on a ‘per-second’ interval.
For example: if I set my trend sensor to 0.02 (+5%/minute?) the sensor doesn’t get triggered (whilst the humidity chart tells me that this increase was reached).
Also I now see the following in the post above:
0.017 is 5.1 in 5 minutes
0.02 is 5% in 1 minute
Which one is true (if any)? How is this calculated?
The trend sensor isn’t polling anything “per second”. The trend sensor updates ONLY WHEN the underlaying sensor updates. This will force you to tune the “sample_duration” value to adapt. For instance, the Xiaomi Aqara temperature/humidity sensor updates once in a while, when there’s a change but also “sometimes” when nothing changed.
As for the calculation method, you can’t trust my comment in the configuration. I just copy/pasted what I have in my binary_sensor.yaml file and, because I did tweak the trend sensors a lot, the comment ain’t correct. Hence the commented “max_sample” too.
You should calculate a rate per second, so 0.06 is 3.6 points per minute (3.6 / 60), not 7.
0.02 is 1.2%/min (1.2 / 60).
If your 0.02 gradient (which is not very hard to get in a bathroom) doesn’t trigger anything, there are 2 possibilities:
see what your samples are, how many and how old they are. If the sensor gives 1 value per second, with only 2 samples, it could not work (too frequent, not enough older samples)
the binary sensor is already on ! (because 0.02 is a small amount)
Thanks for sharing these insights in the trend sensor; I did not have the same understanding based on the documentation. Anyways my sensor, although not Xiaomi, behaves in a similar way. The sensor now works (made a typo earlier) and although it’s only switched on briefly, it’s sufficient to trigger the fans. Now I need to realize the same to detect that humidity level is no longer changing and therefore fans can be switched off again.
Mister_Slowhand, I was wondering. and the reason I am looking at variables… how do you decide when the ventilation system can be turned off? (in my case the Turbo mode that uses double the electricity consumption)
I appreciate different insights… It looks as you have done the same…
I was previously turning my exhaust fan on when the humidity was 10 higher than the house baseline and off when 7 higher.
I just set up 2 trend sensors, 1 with a positive gradient of 0.02 and 1 negative gradient of 0.02
The negative sensor is most useful as it can be put in the condition of my automation for turning off, now it not only needs to be less than 7 but also needs to have stopped falling.
Why did I not just lower the target to less than 7? Because the fan stays on when it rains.
I wonder if I can just rely on the trend sensor alone to turn it off? I feel if the shower is producing humidity whilst the fan is on, the gradient may be low.
It is not so useful for turning on the fan as the humidity can creep up below the gradient but still exceed 10. One example is towels on the radiator drying. I may use it for faster turn on response but still need the difference rule I already have as a low gradient would be too sensitive.
I gave up on the trend sensor as in my (limited) experience this sensor indicates a trend of ~0 if the change is constant. For example the trend sensor is able to detect a humidity increase or decrease but is not usable to determine whether the decrease has reached a certain level (e.g. no less then -1% per x time).
I now use the statistics sensor instead.where I monitor the ‘change’ value. If change is > 5 then switch on the fans. If change was < -2 but is now increasing again (e.g. binary sensor switches from on to off) then switch off the fans (as the humidity change is too limited). On top there is a timeout to ensure that after a given time (say 3 hours) the fans will switch off anyway.
I do not in fact ! These rules are for the whole house vent, that covers the bathrooms, kitchen and some other places. Most of the time this should be on, I turn it off only when heating goes on, at night and when inside humidity is way below outside.
I use the trend sensor to force it on when I detect in kitchen or bathroom that humidity raises. And I don’t care it stays on.
In your case, I would make another trend, inversed, to monitor the humidity decrease. And either stop it when the trend turns off (doesn’t dry anymore), or stop it when it is on for X minutes. In the first case, you’ll need to know the status of the fan.
You can also check on the trend value, accessible as {{ (states.binary_sensor.TRENDNAME.attributes['gradient'] | float) < VALUE }}
Remember that it’s a binary sensor, so it only tells if it’s on or off, there’s a gradient attribute and also the underlaying entity to monitor values. You can use those for triggers or conditions based on values.
@Mister_Slowhand, we both have a different use case it seems. However I did try the trend sensor and what I noticed in the past few days is the following: humidity decreases (fan on), trend sensor activates at roughly -2% per 5 minutes (so decrease of humidity), after a couple of minutes(!) the trend sensors switched from on to off (triggering my fan to go off) because what I believe is caused by the humidity decrease has stabilized (e.g. -4% per x time) and therefore the trend is ~0. I did try different sample durations, gradients and max_samples but all with roughly the same result (being fan switched off way to early.
@sparkydave
this is what I use in my setup. Note that I use sliders (as described earlier in this post) to ‘tweak’ the value for the sensor to go on/off via the GUI. Don’t forget to define the time somewhere…
Binary sensors:
- platform: template
sensors:
bathroom_humidity_rising:
friendly_name: "Bathroom Humidity Rising"
icon_template: mdi:water-percent
value_template: >-
{{ states.sensor.bathroom_humidity_stats_mean.attributes.change | int >= states.input_number.fan_on.state | int }}
bathroom_humidity_dropping:
friendly_name: "Bathroom Humidity Dropping"
icon_template: mdi:water-percent
value_template: >-
{{ states.sensor.bathroom_humidity_stats_mean.attributes.change | int <= states.input_number.fan_off.state | int }}
I’ve tried using this and it works for very quick showers where the humidity is still rising by the time you have finished the shower. That results in humidity also dropping quickly. You get a humidity change profile that resembles:
(shower on) 2,4,(fan on) 6,10,16,12,16 (shower off) 14, 16, 9, 3, -10, -5, -6, -4, -3, -4, -2 (fan off)
I’ve found the problem is on a humid day, or if you have a longer shower, the humidity reaches a peak and the change slows down causing the fan to turn off while you are still in the shower. You get a humidity profile that resembles:
(shower on) 2,4,(fan on) 6,10,14,11,5, 3, 2 ,1, 0 -1, (fan off) 0, 1, 2, 0, -1… … (shower off)
There is a good chance that the fan won’t turn on either now as the room is saturated it will only very slowly dry out without the fan. The humidity change now is limited to small shifts up or down which won’t trigger the fan.
Here is what I am currently using - I am comparing the humidity to another sensor in the lounge which adjusts for humid days.
The fan will also turn on if the humidity rises quickly for fast response but also turns on if it exceeds the humidity of the lounge, this allows for slow increases in humidity. The fan runs until the room is not drying any more which is the bit I am really pleased with. It probably only needs 1 trend sensor as it has a + or - gradient value to show which way the humidity is moving that can be used directly.
I’ve solved this by checking the ‘last update’ value of the ‘humidity_dropping’ sensor. If the dropping sensor goes from on to off (humidity change is no longer below threshold) the fans can switch off. This compensates for any fluctuations
trigger:
- platform: state
entity_id: binary_sensor.bathroom_humidity_dropping
to: 'off'
for:
minutes: 5
@Crhass how do you calculate the gradient? I’m trying to see if humidity rises 5% in a minute. Or 3% in 30 seconds. Is there a formula?
I’m using a bmp280 sensor on an Arduino and it is updating every second, and my corresponding ESPHome is showing the humidity change nearly instantly in the UI. If I blow on the sensor it immediately jumps up. I’m just completely in the dark on how to set up the trend sensor.
The gradient is measured in sensor units per second - so if you want to know when the temperature is falling by 2 degrees per hour, use a gradient of (-2) / (60 x 60) = -0.00055
I’m taking a less-coding but more-hardware approach to this.
I have 2 Aqara Temp & Humidity sensors in my bathroom area - one in the doored-off section with the shower and the other in the area with the sink.
I have a template sensor that compares the % of the two. The fan goes on when the difference hits 7%, and I have it go off 1 minute after it comes down to 2%.
I think I’ll end up tweaking the thresholds a bit to tighten things up a bit, but so far - it’s working.
I found that my fan ran when not required such as when raining outside and outside humidity is around 100%. Using the average sensor (from the min max sensor) and including all humidity sensors in the house (including the room with the fan) and the outside humidity gives a better value to compare. I turn on at 15 above average and off at 10 above. I have left in the statistic sensors to keep it on if humidity is still falling but I am not sure it’s still needed with this method.
I just copy/pasted what I have in my binary_sensor.yaml file and, because I did tweak the trend sensors a lot, the comment ain’t correct. Hence the commented “max_sample” too.