Home Assistant’s current long-term statistics mechanism does not support binary sensors (binary_sensor.* ). This leads to data loss for discrete sensor state changes (0 → 1 , 1 → 0 ) over time, as they are not stored in the compressed long-term statistics format. Given that binary sensor data takes up minimal storage, it should be preserved in its original form without aggregation.
Current Issue
Binary sensors are excluded from long-term statistics: The current implementation only supports numeric sensors. Binary state changes are stored in short-term history (recorder ), but are deleted based on purge_keep_days settings.
Loss of historical binary sensor transitions: Since binary sensor data is only kept in recorder , transitions (0 → 1 , 1 → 0 ) are lost once history is purged.
Inefficiency of aggregating binary data: Unlike numeric values, which benefit from downsampling, binary sensor states should not be aggregated because their transitions are the most important data. Without them, valuable event history is lost.
Workarounds are inefficient:
Increasing purge_keep_days bloats the database.
Storing binary states as numeric (0/1 ) in long-term statistics results in transition loss due to time-based downsampling.
External solutions like InfluxDB or logging to a file do not integrate well with Home Assistant’s built-in history and UI components.
Proposed Solution
Extend Long-Term Statistics to Support Binary Sensors
Implement a dedicated storage format for binary sensor transitions that preserves 0 → 1 and 1 → 0 events without aggregation.
Ensure that binary sensors are stored in statistics in their original state instead of being subject to numeric downsampling rules.
Introduce a New Table in the Database (or ExtendstatisticsTable)
Store timestamped transitions for binary_sensor entities.
This should work similarly to how recorder stores history, but without purging based on purge_keep_days .
Ensure Compatibility with Existing UI Components
Allow binary sensor transitions to appear in history , logbook , and statistics graph card .
Ensure that transitions remain queryable over long periods, just like long-term statistics for numeric sensors.
Benefits
Preserves binary sensor data indefinitely without excessive database growth.
Eliminates the need for inefficient workarounds (e.g., converting binary sensors to numeric values, relying on external databases).
Enhances analysis and historical tracking of discrete events (e.g., motion detection, door openings, switch toggles).
Brings binary sensor data storage in line with best practices in industrial SCADA systems, where all state changes are preserved.
Conclusion
This feature would ensure that Home Assistant provides robust and reliable long-term tracking for discrete events, making it more suitable for automation, security monitoring, and industrial use cases. We request that developers consider implementing this enhancement in a future release.
Sorry if this is not the appropriate place to ask this, but if someone wanted to work on this and contribute it back to Home Assistant Core, would that typically be accepted as long as it follows all processes, etc? Or do we have to wait for a ‘blessing’ by someone or a committee of maintainers before it would make sense to start implementing?
I could take a whack at it, but I don’t want to spend a bunch of time if there’s no chance it will be accepted. Or if this is possible to implement via HACS or some other plugin system, I could do that. But it isn’t obvious if its possible to modify core functionality in that way so it might need to be in Core.
Thanks! I appreciate it. I was just curious what the process would be. Do you happen to know if this sort of thing could be implemented in HACS, or would this require changes in Core?
Already left my vote. I’d still like to express my surprise that the long term statistics did not cover this. After running statistics on my heat pump over the last months and having an eye on a number of metrics here and there I just sat down and when doing long term analysis after this year’s heating period I was stumped and quite disheartened that the long term statistics did not include vital information that I thought would be recorded … … Now I’m missing data about when/whether the electric heater was used, how often certain pumps worked … and other things that are relevant for optimal operation of the system.
I think the disappointment comes from the fact that to me it wasn’t obvious that the system wasn’t recording everything in the same reliability. I used to use Grafana/Prometheus where I knew that if it’s in the system, then it’s in the system, but decided to switch things over to HA because the overall product level and ease of use is much better.
However, this kind of gap was a big shock and a disappointment in the high level of confidenc and trust that I built up over the last months.
I get that things happen and nothing is ever perfect, so let me close with this: I’m sending much love for all the effort and work, really! Thanks for such a great system.
I’d love to see this prioritized because it’s a big gap that users can fall into and - like me - only learn after the fact that they’ve lost months of important data unknowlingly …
I’ll increase recorder retention time now and hope that I can cover it with sufficient disk space …
I left my vote, I have binary sensors for a lot of things, amongst one is “asleep”, I hoped I could see statistics over how much sleep I got… but no. But I can see it’s been off and on in the history. That is just… odd.