Statistics Attributes - Change Rate is constantly 0

Configuration
1

I’m trying to control my dehumidifer by using a Shelly H&T.

In my opinion, using the actual humidity reading isn’t the best approach, instead I should be using rate of change - as that reaches zero, then the room is “dry enough”.

I am reading the Shelly data via MQTT:

  - platform: mqtt
    name: "Shelly HT 1 Humidity"
    state_topic: "shellies/shellyht-F2BA00/sensor/humidity"
    unit_of_measurement: '%'

and then using the Statistics Sensor to get HA to generate stats:

  - platform: statistics
    entity_id: sensor.shelly_ht_1_humidity

As the value of humidity is rising and falling (and fairly static), then I would expect the “Change Rate” attribute to vary, but it’s a constant zero:

image
image352×635 11 KB

I put the attributes through a template sensor to trend them:

      humiditychange1:
        friendly_name: "Humidity 1 Change"
        unit_of_measurement: '%'
        value_template: "{{ state_attr('sensor.stats_2', 'change') }}"      
      humidityroc1:
        friendly_name: "Humidity 1 Rate of Change"
        unit_of_measurement: '%'
        value_template: "{{ state_attr('sensor.stats_2', 'change_rate') }}"      
      humidityavgchange1:
        friendly_name: "Humidity 1 Average Change"
        unit_of_measurement: '%'
        value_template: "{{ state_attr('sensor.stats_2', 'average_change') }}"

image

The red line (rate of change) is a flat line at zero.

Is this a bug, or have I misconfigured something?

Thanks for any insight

2

Haven’t you considered using trend binary sensor?

3

Yes it is not a good approach. I’ve found using this sensor much better:

Though it still requires some external conditions.

I automatically turn my dehumidifiers on when the mold indicator is above 70% (this will depend on your calibration, plus lots of trial and error, though it is a good place to start) and the outside temperature is below 10°C. This worked very well to control condensation on my windows last winter. I found 4 hours to be a maximum run time of diminishing returns so turn them off for 60 min after that time if the readings are still high.

I have another automation that runs at midday and checks the forecast minimum temperature. If it is going to be below 10°C and the current humidity is high ( more than 55-60% depending on the room) I run them for 4 hours to get a head start on the night.

I had high hopes for the VPD sensor but have found it about as useful as the mold sensor. i.e. still requires some conditions.

4

Thanks @tom_l, never heard about this sensor and will give it a go.

5

Wow. :smiley: I had no idea that these two sensors existed.

Bizarrely, even searching for them doesn’t reveal them unless I go to the Integrations root page, but that’s another subject…

OK, I’ll give these suggestions a go as well - thanks - but, for completeness, I don’t see why the Change Rate is a constant zero, so I’ll raise a ticket as well, just to highlight this… it may well be that the documentation needs a tweak…

As always, it’s interesting to see how others approach these solutions.

6

well, there is no point for it to be 0 all the time so it’s either a) input error or b) error in code

7

Drop your sample size to 2 for instantaneous change rate rather than the average change over the last 20 samples (which could be 10 minutes if your sensor samples every 30 seconds).

8

Getting somewhere with the Trend integration examples… I now have Humidity Falling & Humidity Rising indicators…

Reducing sample_size to 2 doesn’t appear to have made any difference, but I’m now playing with max_age too, so some good pointers there… I’d not considered that… :thinking:

9

Reviving this old thread because I struggle with the same limitations

My guess:
A statistics sensor with a humidity sensor as a source will output a statistics humidity sensor.
As the humidity cannot be lower that 0%, negative values will become 0%

My use case is to keep ventilating the bathroom as long as the value is below 0 over 5 minutes of ventilation. Because further ventilation is useless. This tackles the issue that sometimes outside humidity can be high as well. Unfortunately the statistics sensor limitations will not help me this way.

Any ideas how to tackle this limitation? Can this considered to be a bug?
Perhaps write the values of the source to another type sensor and use that as a statistics source.