Statistics: Use actual start value

Feature Requests
1

Hi,

I have a sensor that updates irregularly. Sometimes once per minute, sometimes it can take several hours for a new value to arrive. I have a statistics sensor that tracks this value for 24 hours.

Given this (simplified version of an actual) situation:

yesterday 06:00 reading = 30
yesterdag 10:00 reading = 40
yesterday 20:00 reading = 50 (last)

The statistics value today at 08:00 reports 10. This is according to the documentation, it’s the difference between the first reading and the last reading within the range.
However, common sense says that the sensor value 24 hours ago is 30 so a more intuitive outcome of the statistics value would be 20. Hence this feature request: use the last reading before the time range instead of the first reading within the time range as the start value for the statistic.

Definition of the statistics sensor:

sensor:
    - name: Bresser51 Rain 24H    # day
      platform: statistics
      unique_id: bresser51_rain_24h
      entity_id: sensor.bresser51_rain
      sampling_size: 4500
      state_characteristic: change
      max_age:
        hours: 24

Thanks for your attention.

2

Use a utility meter if all you want is a daily rainfall total and your sensor never resets.

3

What does this measure?

4

The total amount of rain since the last reset/battery replacement.

5

I’ve considered a utility meter, but this resets at fixed times (e.g. 0:00 for a daily meter) and does not reflect the last 24 hours.

7

Yeah. That’s how rain is measured, per day. Not for the last 24 hours from now. Do you need it for irrigation or something?

8

I just want to know how much rain fell in the last 24 hours and in the last couple of days (e.g. 7 days).
If a lot of rain falls between 21:00 and 23:00 then the next day the garden is still wet, despite the daily total of zero. So I think a 24 hour period makes sense.

9

Currently, the integration only uses state changes, and delete periodically those < max_age from its buffer.

It’d make sense to me that the state at now - max_age would be recorded at deletion time, for accurate statistics.

10

It is quite easy to do with an SQL sensor (PostgreSQL):

sensor:
  - platform: sql
    queries:
      - name: Bresser51 DB Rain 24H
        query: >-
          SELECT * FROM states
          WHERE entity_id = 'sensor.bresser51_rain'
                AND last_updated < CURRENT_TIMESTAMP - INTERVAL '24 hour'
          ORDER BY last_updated DESC
          LIMIT 1;
        column: state
        unit_of_measurement: mm
        scan_interval: 120

and a template sensor:

template:
  sensor:
    # Rain (last 24 hours);
    - name: Bresser51 Rain 24H
      unit_of_measurement: "mm"
      icon: mdi:weather-rainy
      state: |
        {{ (states('sensor.bresser51_rain') | float)
           - (states('sensor.bresser51_db_rain_24h') | float) }}

Unfortunately defining SQL sensors in YAML is now deprecated and removed and the definitions are imported into the UI. This has several disadvantages, e.g. not being able to change the poll frequency anymore. :frowning_face:

1 Like
11

I have exactly the same sensor (bresser5in1) and the same wish (24h sum of rain). Have you found a solution?

12

Look at the post directly above yours.