I’m trying to get some statistics from a binary sensor (oil boiler running switch) and it appears to work properly for up to 10 days total / average but anything over 10 days and the results become daft.
7 day total running sensor;
</># Burner total runtime, last 7 days
</> - platform: history_stats
</> name: Burner_Total_runtime_7days
</> entity_id: binary_sensor.shellyplusi4_08b61fcd8d00_input_3_input
</> state: “on”
</> type: time
</> end: “{{ now().replace(hour=0, minute=5, second=0, microsecond=0) }}”
</> duration:
</> days: 7
This works and gives what appears to be a sensible total running time (28.31hours) for the previous 7 days. I then use a template helper to convert this to average consumption over the period;
{{ states(‘sensor.Burner_Total_runtime_7days’) | float(0) / 7 * 1.92 }}
(1.92 being the conversion from boiler running time to oil usage, L/hr)
The results from this give me an average oil usage over the 7 day period which I can take further to ‘oil remaining’ calculations.
If I use the same process but change the history_stats value to 21days the “Burner_Total_runtime_7days” gives me a total time of 302.58 hours whereas if I manually calculate it from the recorded values I get 86.97 hours - roughly three times the 7 day value and about what I’d expected.
Through playing about with the "days: " value of the history_stats sensor I’ve found I seem to get sensible values up to 10 days but then it goes odd after that.
I’ve searched the forums but can’t find a reason why this should happen or how to stop it. I also tried using the “Statistics” platform rather than “history_stats” but that appears to have double counting issues for days when I restart my HA instance.
My HA is running as a virtual machine under VMware ESXi if that makes any difference.
Any help / suggestions greatly appreciated!
Thanks,
Colin
By default, recorder keeps up to 10 days of history, you might need to extend it. As a side effect, extending the default history size might impact overall db size and probably performance (i don’t notice).
Check recorder integration configuration.
I didn’t check in depth how history stats integration working under the hood but it seems to be highly related recorder limit.
Thanks for your reply - that would seem to fit what I’m seeing but must admit databases make me nervous!
Is it possible to see see how big the database currently is - my HA ability level is barely making it to user so struggle to do many things in HA!
From the link you’d sent about the recorder I’m tempted to increase to 14 days initially and see if that then extends my history_stats total to the 14 days, proving that this is the issue.
To do this is it simply add this to my config.yaml;
The HA “all eggs in one basket” database design makes me nervous, too. My boiler runtime data are saved to text (csv) files where I can easily analyze or report on them using a spreadsheet or other tools of my choice. This may or may not be a good solution for you, but I figured I’d mention it as an option.
Its now 4 days since I increased the recorder retention from default to 14 days and set my sensor for a 14 day average and all looks sensible.
I guess this supports it being an issue with the conversion from the short term data recording to longer term retention? Should I raise this as an issue in the HA reporting / wish list systems?
For anyone coming across this post in the future, adding a Recorder </> purge_keep_days: value to 21 in the configuration.yaml has resolved the issue that I was seeing and I can now do a rolling 21day total of the time my central heating boiler is firing (binary sensor), therefore working out an average and converting to daily oil consumption.
Its not the most targeted approach but has worked for me and doesn’t appear to have altered the overall size of my HA installation. I don’t know how to check the database itself so can’t be more specific.
If any developers have a better solution please update on this post.
My thanks to @CaptTom & @anon63427907 for their input.
Thanks,
Colin
so it is not going to work immediately