Sensor can only be of measurement type or increasing; they don't have to be

[jyavenard]

The problem with last_reset attribute being deprecated and the move in favour of using a state_class STATE_CLASS_TOTAL_INCREASING (see https://developers.home-assistant.io/blog/2021/08/16/state_class_total/)

which indicates For sensors with state_class STATE_CLASS_TOTAL_INCREASING, a decreasing value is interpreted as the start of a new meter cycle or the replacement of the meter. It is important that the integration ensures that the value cannot erroneously decrease in the case of calculating a value from a sensor with measurement noise present. This state class is useful for gas meters, electricity meters, water meters etc.

This leaves no room for sensors that always present a negative value and that will accumulate, or sensors whose sums only ever decrease.

A practical use is with energy sensors where the sign indicates which way the current is flowing.
A device like the iotawatt measures signed current and from the voltage determines the power (P=UI).

As such, an energy production system whose current flow upstream (like when exporting energy back to the grid) will be recorded as a negative sensor that keeps growing.

The integration integration is an example of sensor that can easily produce a monotonically decreasing value over time.

In addition to STATE_CLASS_TOTAL_INCREASING there should be a STATE_CLASS_TOTAL_DECREASING but as it's close to impossible to determine upfront which type of sensor we would have at the time it will be created, ideally we should have STATE_CLASS_TOTAL_MONOTONIC.
and the type should be total_monotonic

To determine rollover or sensor reset, one has to detect if the difference between the last recorded value and the next value has a different sign.

[emontnemery]

In general, this makes sense, but there are two edge cases which makes this tricky:

• How can we reliably detect if a monotonic value is increasing or decreasing
• There is currently a workaround in place which makes a total_increasing sensor not reset if the relative difference between two consecutive states is < 10%, documented here https://developers.home-assistant.io/docs/core/entity/sensor#state-class-total_increasing

Also, please note that Home Assistant's energy dashboard expects all energy sensors to have a positive value; both export and import sensors should have a positive value.

[jyavenard]

The sign of the series is determined as soon as you have two values.

bool is_increasing = state[1] > state[0] # stored forever
bool reset = (state[n] > state[n-1]) != is_increasing
if reset:
  ...

I'm not familiar in the context in which it will be used, and I don't see at a glance why ignoring small changes would make a difference here.

I'm aware of the energy dashboard requirement ; this can be worked around by using a template, which isn't particularly user friendly either. I had to do the following:

sensor:
  - platform: template
    sensors:
      energy_solar_abs:
        friendly_name: "Solar Energy Abs"
        value_template: "{{ states('sensor.total_solar_wh_accumulated')|float|abs}}"
        unit_of_measurement: Wh
        device_class: energy
        attribute_templates:
          state_class: "{{ state_attr('sensor.total_solar_wh_accumulated', 'state_class') }}"

      energy_export_abs:
        friendly_name: "Export Energy Abs"
        value_template: "{{ states('sensor.export_wh_accumulated')|float|abs}}"
        unit_of_measurement: Wh
        device_class: energy
        attribute_templates:
          state_class: "{{ state_attr('sensor.export_wh_accumulated', 'state_class') }}"

I would prefer if there had been a toggle to specify that export and energy production are negative.

Keeping value signed, allows also for simpler and neater calculations such as export+import is always consistent regardless of the size of the interval looked at or the sampling rate at which the measurements are made.

[emontnemery]

The sign of the series is determined as soon as you have two values.

bool is_increasing = state[1] > state[0] # stored forever
bool reset = (state[n] > state[n-1]) != is_increasing
if reset:
  ...

Yes, but how do we know that state[1] is not the first value in a new cycle?

Keeping value signed, allows also for simpler and neater calculations such as export+import is always consistent regardless of the size of the interval looked at or the sampling rate at which the measurements are made.

This makes sense, but the current design of energy dashboard doesn't work that way.

I'm aware of the energy dashboard requirement ; this can be worked around by using a template, which isn't particularly user friendly either.

Where do your sensor values come from, is it from a core integration, a custom integration or something generic like an MQTT or template sensor?

What I'm getting at is that maybe it's easier to require an integration to provide positive values for import and export sensors than to add support for decreasing sensors.

[emontnemery]

This is an attempt at summarizing cases there state class total_increasing is not suitable:

• Sensors with monotonic values which are decreasing (the trigger of this discussion)
• Net energy sensors:
  • Solarlog consumption total sensor: Improvements to the solarlog integration core#55405 (comment)
  • Solar edge and growatt total production may decrease slightly (understood to be because the "total production" includes energy consumed by the inverter)
  • Portuguese energy meters do not separate import and export, but just expose a net total. This is fixed in the latest generation though which are currently rolling out

[jyavenard]

Yes, but how do we know that state[1] is not the first value in a new cycle?

you don't. And in that case you ignore the value of state[0] and continue as before. In the lifetime of the sensor, that first value will be insignificant

Mind you, if we had a last_reset then none of this would be necessary. It would still be be nice to be able to differentiate between punctual reads (temperature, on/off state etc) vs data that should only ever grow or reduce over time but has room for sometimes going both ways (like a solar system that is producing power most of the day, but at night just before the system turns off will start consuming energy)

Where do your sensor values come from, is it from a core integration
I use a iotawatt for energy reads , which is now a core component.

But over the years, I've dealt with constantly decreasing accumulating value. It happens all the time.
Just like measuring expenses vs income. Expenses are negative , income positive. Any accounting tool works that way.

[emontnemery]

I think this is solved by adding the total state class: https://developers.home-assistant.io/blog/2021/09/20/state_class_total

[jyavenard]

Will the energy application accepts those sensors ?