Hi all,
I found several threads about this, but unfortunately no solution. So I figured I’ll test my luck…
I’m tracking my oil burner as a binary sensor with a ESP8266 hooked up to a voltage sense board. The binary sensor works fine and shows when it’s on and off.
This is fed into a history_stats helper to sum up the ‘on’ time to calculate oil consumption and model the dumb physical counter on the heating system.
That in itself also works fine, except for when the binary sensor becomes unavailable due to a system reboot. In that case it records a negative time and throws off my statistics.
There does not seem to be a way to tell the history_stats to ignore ‘unavailable’ and it is not possible to ‘adjust sum’ on the history_stats, which is driving me mad.
Anyone having any idea? (Please don’t start the ‘you shouldn’t have to restart your system regularly anyway’ argument on me. I have my reasons to do so and it is obviously a bug in HA)
Running HAOS 2025.2.4 on a Raspberry Pi 5 in a Proxmox VM
Can’t you add availability logic and when it’s unavailable, have it report 0, or some other number. (Might be as simple as adding a default to the calculation.)
Share your actual code and some of the template guru’s will probably be able to fix you right up.
Are you sure this is caused by the reboot and not the recorder purge? History stats only goes as far as the recorder can hold. There are ways around it, but you need to show what you’ve configured.
The solution is probably a history stats sensor counting use per day and a utility meter summing it all to a grand total.
Yes, it is as I expected. Recorder standard holds only 10 days. So every day you lose the day that is eleven days old, leading to a drop. Recorder is not meant to keep data for very long.
Wht you must do is set the start to the beginning of each day. That way the history sensor is only couning one days use, and then resetting to 0.
start: "{{ today_at() }}"
Then create a utility meter in the helper section and use the daycount sensor as the source. Do not set a cycle of any kind, but make sure periodically resetting is true. This sensor will start counting the total from the moment you create it (wait for the source to change, it will be unavailable until the first change).
The utility meter will not need history, and the history sensor will only need to look back a day. that is always there.
Do I understand your suggest correctly to ditch the history_stats and instead code one myself including a check for availability?
I probably would have done that already if I could code them up in C++ rather than Jinja2
Ah I see. Then it seems that HA aligns the purge with the restart. But seems a bit odd to me that it subtracts the cut values instead of just retaining the latest one as a new start value.
Thanks. I’ll implement it and report back.
Good thing I already have influxDB implemented.
History is simply adding values from the recorder. It is not adding anything to values it calculated before, because the period has changed. It does not know if the starting point is constant or moving through time (like my suggestion), so it cannot use the previous value as a starting point.
For that you might want to consider a (right) Riemann sum integral sensor. You would have needed it if your input was not binary. But I would stick with what you have now if the usage is constant when the binary sensor is on.
