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.
Same surprise here with my furnace and not being able to see data beyond 10 days.
By default the furnace’s duty cycle information is as an attribute, not an entity, so it’s completely discarded after just 10 days by default. Only the temperature and humidity from the thermostat are saved into long-term statistics. I am able to create a graph of indoor-vs-outdoor temperature using ApexCharts and the long-term statistics I have from the National Weather Service integration, but I have no long-term information saved from the default thermostat for duty cycle.
Knowing whether the current furnace is under/oversized is useful data for properly sizing a heat pump replacement in the next year or two.
I have now created a Template Binary Sensor, History Stats rolling 30min ratio sensor, and History Stats previous complete 1hr ratio sensor (e.g. at 2:37p it’s measuring the ratio from 1-2p). But this is a lot of extra useless data getting stored into long-term statistics.
I voted for this and would like a count of triggers per hour (ie aggregation) well as the option to have detail preserved
eg motion events or door opens.
If a state change is recorded (so open and close is 2 counts, motion-detection on & off as 2 events) that would be fine as long as it was clear and consistent across all binary sensors.
Thanks!
You can already do this with template sensors. Just make a template sensor that increments 1 every trigger. Make sure to set the state_class, device_class, and unit_of_measurement and you’ll get stats on the triggers per hour.
… 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.