Statistics sensor - put back time attributes

The recent changes in the statistics sensor have removed a ton of flexibility. I have many things I’m computing change per time but the units are far too small to use the “change per second” because its always zero.

Examples:
-Weather (temp, wind, rain) change per X minute(s)/hour(s)/day
-Power consumption estimates change per hour

These are usually values like a single-digit (or fractional) quantity of change per hour, or in extreme cases single-digit change per few minutes. In all cases they are far below 0.1 change per second.

I used to be able to easily get the change and start/end to compute to any time-interval I desired, but it now seems I can only pick one of those three things. This means I have to have 3-4 separate sensors (change, count, oldest, newest) and hopefully they stay in sync just to do what was trivial to do with a single one before.

The removal of attributes and creation of separate sensors has been happening across all integrations for the past 3 years. Sorry to be the bearer of bad news but the likelyhood of these attributes coming back is extremely low.

What are you calculation? The statistics integration added a ton of new calculation methods that most likely solve your problem without you needing to perform the calculation.

Trying to calculate things like power-use, rainfall, temperature-change per hour.

It doesn’t seem like there is any way to do this right now because the only change-over-time seems to be seconds which is always zero when I try to use it with such small numbers.

Examples:
Rain gauge goes from 1.2 to 1.4 inch in readings 15 minutes apart, its raining at a rate of 0.8 inches per hour.
Power meter goes from reading 12345.6 kWH to 12345.9 kWH across readings 2 minutes apart, I’m using 9kW average power

To accurately compute this, I have to use oldest/newest sample time (because the meters don’t beacon on a fixed interval) and then look at delta seconds between them per elapsed time and multiply that by 3600 to get “per hour” rate.

I tried this with the change_seconds and then multiply it by some number of seconds to extrapolate per-hour except it apparently doesn’t output high enough resolution past the decimal to give any readings for these slow changing values, its always zero, which is useless.

I also in some cases though want units other than per-hour. For some things like temp and rainfall change rate it can be useful to know like per-partial-hour or per-day.

So far, this is the only way I’ve found to make this work but now requires 4 separate stats sensors to compute the same value…

# Compute real time (approximate) usage by measuring the
# time difference between changes and amount of change

sensor:
  - platform: statistics
    entity_id: sensor.power_company_meter_buffered
    name: "Power Company Meter Stats Change"
    state_characteristic: change
    sampling_size: 3
    # age defines how long previous value waits without change assumed zero
    max_age: '00:10:00'

  - platform: statistics
    entity_id: sensor.power_company_meter_buffered
    name: "Power Company Meter Stats Count"
    state_characteristic: count
    sampling_size: 3
    # age defines how long previous value waits without change assumed zero
    max_age: '00:10:00'

  - platform: statistics
    entity_id: sensor.power_company_meter_buffered
    name: "Power Company Meter Stats Newest"
    state_characteristic: datetime_newest
    sampling_size: 3
    # age defines how long previous value waits without change assumed zero
    max_age: '00:10:00'

  - platform: statistics
    entity_id: sensor.power_company_meter_buffered
    name: "Power Company Meter Stats Oldest"
    state_characteristic: datetime_oldest
    sampling_size: 3
    # age defines how long previous value waits without change assumed zero
    max_age: '00:10:00'

  - platform: template
    sensors:
      power_meter_current_power:
        friendly_name: "Power Meter Current Power"
        unit_of_measurement: "kW"
        icon_template: hass:flash
        value_template: >-
          {% if states('sensor.power_company_meter_stats_count') | int(0) < 2 %}
            0
          {% else %}
            {% set rate_calc = ( states('sensor.power_company_meter_stats_change')|float(0) /
                 ((as_timestamp(states('sensor.power_company_meter_stats_newest')) - as_timestamp(states('sensor.power_company_meter_stats_oldest')))/3600)
               ) | round(2) %}
            {% if rate_calc < -100 or rate_calc > 100%}
              0
            {% else %}
              {{ rate_calc }}
            {% endif %}
          {% endif %}

And the output does align with what a clamp meter reports when I check it so its computing approximately correctly but its a really horrible convoluted way to do it now, and I don’t see any better way possible with what’s offered.
image

I’ve not had rain to attempt to rebuild my rainfall-rate sensors since the changes happened but I expect them to be similar if I reuse my old calculations…and have the same problem of small numbers meaning the built in change_seconds will always be zero. And same with temperature change numbers.

If you’re trying to take kW and turn them into kWh, then you should be using Integration - Riemann sum integral - Home Assistant. The method you’re using is right. It would simply be:

sensor:
  - platform: integration
    source: sensor.power_company_meter_buffered
    name: "Power Meter Current Power"
    method: right
    unit_prefix: k
    round: 2

For rainfall, you’d do the same thing.

1 Like

Opposite of that - estimate the rate from the total count. The meter reports total kWH, I’m comparing 2 readings over time to estimate kW draw.

Same with rainfall, taking 2 quantity readings (total inches) at different times and determining the rate.

Shouldn’t need any fancy math, its more or less a basic slope calculation.

So I did just try an experiment, it looks like if I “pre-scale” the input to a really big number (say multiply by 10,000) and then “post-scale” it back down dividing by the same quantity after the “change_seconds” will give me what I need.

Maybe the “fix” should be a way to specify the precision/resolution of the change_seconds so I could get like 5 places past the decimal point to get useful readings out of the sensor?

if you want the opposite of integration then you use a derivative…

sensor:
  - platform: derivative
    source: sensor.power_company_meter_buffered
    time_window: "00:10:00"

EDIT: Just so you know, a derivative is the rate of change. In this case, it will be the rate of change over 10 minutes, which is the value you’re looking for.

1 Like

Hmmm, tried this a bit and it doesn’t seem to work the same way. Seems like its always over 10 minutes vs being “up to” 10 minutes but using only the most recent 2-3 updates like the way I was doing was. I’m not seeing a way to limit the window of sample size with derivative like the statistics sensor supports.