I saw the last_reset is needed to make stuff function, but almost no integrations are using this and the whole concept is not needed als far as I’m seeing. Take a resetting counter:
counter:diff
0:NaN
10:10
15:5
2:-13 → it’s reset. Discard value, use 2 and generate timestamp
This is how influx (non negative derivative) or elastic/kibana (positive rate) do it as well. My kwh counters have been working perfectly for years without the need of such a topic.
Why bother with an extra topic where providers need to implement this exact same logic themselves?
Yes please remove this constraint that breaks many integrations.
Apparently it is not needed anyway.
Alternatively give the capability to add this attribute in template with a dummy value.
Currently the only work around that seems to work is to use of utility_meter integration
It seems, if I understand correctly, that long-term statistics requires specific properties. One of them is that the state_class should be set to measurement. But apparently more are required for this work.
I am using a ESP device that it programmed with the telinfo device (Teleinformation from Linky electrical counter. — ESPHome). It read information transmitted by an electrical meter connected to the grid like total energy since installed, voltages (plural as I have three-phases), intensities, instantaneous power, etc.
As already said unfortunately the energy reading from this integration cannot be used directly and as a workaround, I use an utility_meter.
I was hoping to use the statistic graph card on some other sensor but it does not work and I do not know why? For example I have a sensor for the current I added some directives in the sensor declaration and now it looks like that:
state_class: measurement
unit_of_measurement: A
friendly_name: Grid I1
device_class: current
Seems like I have all requested properties? However, it does not work? Do you why and how to fix it?
I don’t know about the statistics card. For the energy panel you need
device_class: energy
unit: Wh or kWh
state_class: currently measurement; next release any of the 3 (see PR in post above)
last_reset: time of Last reset or 0-timestamp; next release this will not be needed necessarily / even be deprecated
So you see there is a lot of shuffling around currently. I’d just wait until 2021.9 (2,5 Weeks) or maybe even another release - for the dust to settle.
With both, statistics and energy, a new value is created every hour (I think 12min past the hour) so it takes some time for the graphs to appear.
Yep, dropping last_reset is totally needed. Additionally for the state_class, it should be total_increasing instead of measurement. Guess we will change our configuration once new release hits.
This is great.
Currently I am using a utility meter as a workaround but unfortunately for total_increasing type of sensor it does not work perfectly: each time HA is restarted (this happen a lot as I am experimenting with Energy management and statistics) the utility meter report increasingly wrong value.
see Utility meter sensor reports wrong value after HA restart · Issue #54932 · home-assistant/core · GitHub
PR has been closed for reasons I understand (even though I would not have it implemented like that)
