- platform: history_stats
name: 'Fruit Trees Valve 10 Day On Time'
entity_id: switch.fruit_trees_valve
state: "on"
type: time
end: "{{ now() }}"
duration:
days: 10
Anything in the logs that might be useful for us?
No errors appear to be generated.
Additional information
This could be either a bug fix or a suggestion. If it's a bug, the fix would be to prevent the History Stats sensor to attempt to include any data (that doesn't exist) if the Recorder Purge value is set to a shorter time than the History Stats time duration.
If this can't easily be fixed, then one option would be to update the History Stats code to read the current Recorder purge duration and generate a message (or error) telling the user that the results will be inaccurate unless the Recorder purge value is increased or the History Stats duration is decreased to match the Recorder value.
As a last option, the documentation should be updated to mention that the History Stats time based values will be inaccurate if the duration is set to a longer time than the Recorder. Currently the documentation only indicates that the values will be based on the length of time set in the Recorder purge_days, but fails to mention that those results can be wildly inaccurate.
home-assistant[bot]
commented
2 months ago
The problem
Odd values are generated when creating a new History Stats time based sensor if the duration is set longer than the Recorder purge days. The issue is described in this community thread: https://community.home-assistant.io/t/history-stats-not-working-as-expected/766212
What version of Home Assistant Core has the issue?
core-2024.8.3
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant OS
Integration causing the issue
History Stats
Link to integration documentation on our website
https://www.home-assistant.io/integrations/history_stats/
Diagnostics information
No response
Example YAML snippet
Anything in the logs that might be useful for us?
Additional information
This could be either a bug fix or a suggestion. If it's a bug, the fix would be to prevent the History Stats sensor to attempt to include any data (that doesn't exist) if the Recorder Purge value is set to a shorter time than the History Stats time duration.
If this can't easily be fixed, then one option would be to update the History Stats code to read the current Recorder purge duration and generate a message (or error) telling the user that the results will be inaccurate unless the Recorder purge value is increased or the History Stats duration is decreased to match the Recorder value.
As a last option, the documentation should be updated to mention that the History Stats time based values will be inaccurate if the duration is set to a longer time than the Recorder. Currently the documentation only indicates that the values will be based on the length of time set in the Recorder purge_days, but fails to mention that those results can be wildly inaccurate.