Allow per-entity recorder configuration (e.g., different purge or inclusion behavior) #380
Unanswered
amuamurawski
asked this question in
Core functionality
Replies: 1 comment
|
Adding a few related references here for context:
My discussion also contains some real-world database measurements showing the impact: ~85.6 million Leaving these references here in case they are useful for evaluating this feature request. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Describe your idea
I propose extending the recorder: integration to allow per-entity configuration of history logging behavior. Instead of applying a single global purge_keep_days and inclusion/exclusion logic, users should be able to define specific rules for individual entities, such as:
• How long to keep history (purge_keep_days)
• Whether to store state history and/or statistics
• Whether to override global exclude rules
This would be implemented via a new per_entity or per device type etc...: section under recorder:.
Why is this exciting?
This feature adds flexibility, efficiency, and clarity to how data is managed in Home Assistant. It allows users to:
• Retain important long-term data (e.g. energy, gas) for years
• Reduce clutter by excluding or shortening retention for noisy entities (e.g. motion, temperature spikes)
• Avoid bloating the database with data that’s irrelevant for analytics
• Fine-tune performance for larger HA installations or limited-storage environments
• Make recorder act more like a real data retention policy engine, not just an on/off switch
Potential use cases
Dream up some scenarios where this would be amazing.
• Store sensor.energy_total for 5 years to enable long-term consumption analysis
• Keep sensor.outdoor_temperature for 60 days for recent climate review, but no longer
• Record presence sensor sensor.czujnik_obecnosci_kuchnia for 30 days for automation debugging, while ignoring all other presence sensors
• Exclude sensor.battery_level_* by default, but include sensor.battery_alarm_clock due to its critical role
• Disable statistics for sensors that generate low-value or erratic data (e.g. sensor.zigbee_noise_level)
Anything else?
No response
All reactions