I still don't understand how to use the trend sensor for humidity


I’m still figuring out the trend integration:

Its there some one that wants explain it to me in even more dummy style how to calculate it? :blush:
I just don’t seem to get it.

I have a sensor that measures humidity. It updates every 10seconds.
It’s clearly that when you start showering, there is a increase of 5 points within 1minute.

Whe you stop showering there is a decrease of 3 points within 1 minute.

So I’d like to make 2 trend sensors, one detecting the start of the trend (showering) and one detecting the stop of this trend.

I need these triggers to start and stop the bathroom fan. Since using a standard/regular humidity value doesn’t work because the base-value varies trought the day and year. But “a sudden increase” or decrease is always the same, so the trend sensor would be very handy. I’m trying to figure out what to fill in the yaml

  - platform: trend
        entity_id: sensor.nrg_itho_c1f4_humidity
        sample_duration: ?
        max_samples: ?
        min_gradient: ?

  - platform: trend
        entity_id: sensor.nrg_itho_c1f4_humidity
        sample_duration: ? 
        max_samples: ?
        min_gradient: ?


1 Like

instead of using a trend binary sensor you could use the derivative sensor and trigger on either a positive or negative derivative value.

here is a sensor I use to check the rate of change of my fish tank temperature:

  - platform: derivative
    source: sensor.tank_sensor_temperature
    name: Tank Temperature Derivative
    round: 3
    unit_time: h
    time_window: "00:30:00"  # change over the last half hour
    unit: '°F/Hr'

this is how the result looks as a graph:


I know how fast (in F/hr) the temp is increasing or decreasing and I would use that in my automation to trigger the notification.

you might need to change the time span to catch what you want in a few minutes but you can use it as is by just changing the source to your humidity sensor to see if it works like you want.

1 Like

I don’t completely undestand what derivative does, maybe because i’m not a native english speaker but I see the Derivative output’s a sensor in in %/minute. So I think you suggest if the sensor gives a sudden increase of 5%/minute I could trigger on that. And if there is a decrease of -3%/minute i could trigger on that… Oke thanks! I’m gonna try that. Let’s see what happens :slight_smile:

Your idea is OK, just like the below suggestion of derivative is OK. I compare with a sensor in a different room, also works.

For the specific above, you have put in -0.0008 for the rising sensor, should be a positive number. And for the declining trendsensor, the min_grandient should also be a positive number, and you should use the “invert” parameter, as mentioned in the docs.

I’ve edited my post. The point was that I didn’t understand the math, what to fill in.

Try this. Maybe change grandient. Used 20 samples, just to be sure you got 60 seconds

Thanks for the values, trying this out. Will take some time.
I’m still wondering how to calculate the min_gradient.

When i’m reading the example I fill this in:
…bla bla trend over 60seconds and your sensor updates every 10s then max_samples must be at least 60/10 = 6

…a trend line is then fitted to the available samples, and the gradient of this line is compared to min_gradient to determine the state of the trend sensor. The gradient is measured in sensor units per second - so if you want to know when the temperature is raising by 5 points per minute, use a gradient of (6x6) = 12. So 5 / 12 = 0,41

I’m probably wrong going wrong in my head understanding this…or am I correct?

P.s. With points i mean % since this sensor is from 0 - 100% humidity I can calculate with normal values from 0 - 100. To decomplicate the calculation i’m not talking in percent% but in regular numbers (points).

Think it is easier.

It is change pr second. As you expect it to change 5 in 60 seconds, it is 5/60=0.083

I set max_samples to 20, just to be sure. It does not matter, just make sure the number is large enough to cover the sample_duration. If you use 6, then you might be missing out on readings if for some reason it fires a few extra.

1 Like

Yes, that’s exactly what I was thinking.

1 Like

Thanks! No I understand how it works. Both solutions are interesting!

Also looking to achieve this, my sensors need some refinement and interested to see what you find working well for you

Just to increase choice stress and possible resulting analysis paralysis :crazy_face:

I use a different approach for the shower detection that I implemented on a system that didn’t have trend sensors or derivatives, and worked well so I never converted it: I compare the bathroom humidity to the humidity in an adjacent room. That gets around the climate variations in the base line humidity.

I use it to turn on the fan. I have a hunch it works better for determining when to stop the fan, because I do not want to stop when the humidity lowers but when it is back to normal. But waiting for a flat trend is something that also happens at the top of the humidity levels. But then again, I think a trend sensor might be quicker catching the start. I may need to compare when I have time…

1 Like

Yeah i read about your “compare to other baseline” solution. It’s a bit complicated but smart.
I Can’t tell yet what works for my situation.

Seems i’m able to catch the “stop-shower” -trend, with a false positive but these can be ruled out with combining the automation with another trigger like “if the gas is on, the light is and there recently is movement detected” something like that.
But my start “detect-shower” -trend sensor stays “Unknown”. I don’t know yet why.

De derivative sensor excists and I see some activity there. Look promising, needs further study.

I’m also trying to work out the best way to go. A Trend sensor has a Gradient attribute, which is equivalent to the Derivative sensor. I am plotting the Trend, Gradient, and raw data, which is the sum of the difference between the set point and actual temperatures of 11 radiators. Like in the original post, I want to start the radiator pump when the difference is trending up, and turn it off when the difference is trending down.

The problem is that I cannot work out what values to use, and it seems that the Gradient value doesn’t change if the input sensor value doesn’t change.

The top graph displays the sum of differences, which is the input to the Trend sensor. The graph at the bottom displays the Gradient of Trend sensors I have configured with different settings.

What I don’t understand is that if the input value doesn’t change for some time, the Gradient should show an exponential trend to 0. Instead it shows the same value until the input sensor value changes.

This is my YAML code

      unique_id: tado_total_load
      friendly_name: "Tado Total Load"
      unit_of_measurement: '°C'
      value_template: >-
        {{ states('sensor.bunker_load') | float() +
            states ('sensor.dining_room_load') | float() +
            states ('sensor.downstairs_hall_load') | float() +
            states ('sensor.entrance_hall_load') | float() +
            states ('sensor.guest_bedroom_load') | float() +
            states ('sensor.kitchen_load') | float() +
            states ('sensor.living_room_load') | float() +
            states ('sensor.master_bedroom_load') | float() +
            states ('sensor.office_load') | float() +
            states ('sensor.social_bedroom_load') | float() +
            states ('sensor.upstairs_hall_load') | float() }}

      unique_id: tado_load_gradient_60
      friendly_name: Tado Load Gradient 60
      unit_of_measurement: '°C/min'
      value_template: >-
        {{ state_attr('binary_sensor.tado_load_trend_60','gradient') | float() * 60.0 }}

      unique_id: tado_load_gradient_120
      friendly_name: Tado Load Gradient 120
      unit_of_measurement: '°C/min'
      value_template: >-
        {{ state_attr('binary_sensor.tado_load_trend_120','gradient') | float() * 60.0 }}

      unique_id: tado_load_gradient_180
      friendly_name: Tado Load Gradient 180
      unit_of_measurement: '°C/min'
      value_template: >-
        {{ state_attr('binary_sensor.tado_load_trend_180','gradient') | float() * 60.0 }}

      unique_id: tado_load_gradient_240
      friendly_name: Tado Load Gradient 240
      unit_of_measurement: '°C/min'
      value_template: >-
        {{ state_attr('binary_sensor.tado_load_trend_240','gradient') | float() * 60.0 }}

      unique_id: tado_load_gradient_300
      friendly_name: Tado Load Gradient 300
      unit_of_measurement: '°C/min'
      value_template: >-
        {{ state_attr('binary_sensor.tado_load_trend_300','gradient') | float() * 60.0 }}
- platform: trend
      entity_id: sensor.tado_total_load
      sample_duration: 60
      max_samples: 120
      min_gradient: -0.0008
      entity_id: sensor.tado_total_load
      sample_duration: 120
      max_samples: 120
      min_gradient: -0.0008
      entity_id: sensor.tado_total_load
      sample_duration: 180
      max_samples: 120
      min_gradient: -0.0008
      entity_id: sensor.tado_total_load
      sample_duration: 240
      max_samples: 120
      min_gradient: -0.0008
      entity_id: sensor.tado_total_load
      sample_duration: 300
      max_samples: 120
      min_gradient: -0.0008

Everything in these sensors updates when the source sensors update. If they don’t update for a long period, the resulting sensor will not update for that period either. No new samples → no new updates.

Huh, but usually sensors don’t update unless the value changes. change. I agree with the poster that if there’s no value change for an extended period then the derivative should be 0. If it doesn’t then That makes the implementation fundamentally flawed i.m.h.o. for the average sensor. You cannot determine the change over time if you do not consider the passing of time a relevant change. I wouldn’t know how to fix it either, other than introducing noise in the original sensor value.

It considers the time but doesn’t update the calculation until a piece of data comes through. It does not constantly calculate, it’s based off samples. It’s not going to make up samples. Please, do not start another argument with me about how something functions. I’m not sure why you always seem to target my posts, just move along when you disagree some behavior I’m describing. I’m just describing how it works, I’m not here for a debate.

1 Like

I’m not saying you are wrong when you tell us how it is implemented, nor do I think you are in any way responsible for if that is correct. I’m happy you tell us how it is implemented, it helps to understand the results that we observe.

But you only answer how it is implemented, while I raise the question on wether that implementation fits the purpose at hand. That is an entirely different question. If you do not want to give you opinion on that, fine - but don’t get mad at me for asking the question.

I think a sensor is flawed when the only way to understand its results is to know how the sensor is implemented. I’m not looking for fancy algorithms, I’m interested in the right behavior for the right task.

For me this means that the derivative sensor’s behavior is not very useful in situations where the original sensor does not always change very frequently. It also does not always do what the name implies, nor can I think of a way to work around the ill effects of this implementation. So I won’t use it in its current form.

You didn’t ask a question… you simply chimed in and told me why it’s not good. I’m not here for that, I’m here to help. Go make Feature Requests if you don’t like behavior and leave me out of it, thanks.

1 Like

Since the derivative integration does not adhere to one of the most basic rules of derivatives:

I posted a bug report:

1 Like