core: history_stats sensor does not reset until slightly after midnight for the next day
The problem
History_stats gives a wrong value if the sensor used as the base for the measurement is “on” over midnight and you want to measure a daily value.This problem has been reported before (#72357) but this issue was closed without action.
The following sensor is used to keep track of the daily usage of a water tap:
- platform: history_stats
name: Waterfill daily
entity_id: switch.poolwater
state: "on"
type: time
start: "{{ now().replace(hour=0, minute=0, second=0) }}"
end: "{{ now() }}"
This speciIfic night switch.poolwater was open less than 5 minutes:

The history stat sensor should present 3m14s for July 27th and 22s for July 28th. But it continued to count all day ( today) even if the switch turned of 22s after midnight. In the morning it looked like this:

What version of Home Assistant Core has the issue?
2022.7.5
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
No response
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
Not sure if this problem occurs everytime the sensor is open over midnight. I’ve seen this problem before monitoring another sensor, but I thought it was corrected in a later release. See https://community.home-assistant.io/t/strange-history-statistics/433815 for additional details.
About this issue
- Original URL
- State: open
- Created 2 years ago
- Reactions: 7
- Comments: 34
This is still an issue. Such a fundamental logic shouldn’t require multiple sensors and workarounds to work.
Following documentation should result in correct MAX value, but that is not the case and therefore this is an issue yet to be resolved
having exactly same with mine history_stats
while the switch pc_s got turned off yesterday
This definitely still needs attention as I’m pretty sure it hasn’t been addressed. I have a workaround in place but it should just do what it says it does.