WTH can't I define multiple different recorder times for different entities?

Tags: #<Tag:0x00007fc4162f8208>

Some entities require only one or two days history, so you can have a look at what happened yesterday, and some entities you want to remain in the database for a long period to see how your energy usage evolves for example, or how much rain there was in the same month last year.
It doesn’t require all measures, but most of the time only totall of the day or something, and keep that for long time. Why isn’t this possible?

For long-term data I would suggest using InfluxDB, which is a time-series database.

3 Likes

This is a must have enhancement. I keep my history for 7 days, so that I can monitor my smart meter for usage and costs, but I also would like to assign 1 or 2 days for other entities that I use in graphical displays. This would help keep my DB at a reasonable size so that I can make a copy off it every midnight via an automation that must finish within the 60 second time window before it times out.

1 Like

I wanted to chime in with a +1 here.
I already use InfluxDB for long term data storage and graphing in Grafana, but HA-native graphing of selected entities long-term would be far easier to configure for the majority in a SQL database. SQL is more known and has more tooling, and most importantly, a lot of users already have a SQL DB in place.

My case right now is that I want to store awake/sleep timestamps daily, indefinitely, and then do some math-over-time on them and display it with a custom card. If I could configure specific recorder rules for those two input_datetimes in the recorder it would be easier to share with other HA users.

There is another solution to this, at least for mysql/mariadb, which is to use event scheduling to copy selected state data into a new custom table – which is the route I’ll most likely go.
Perhaps this entire WTH is just as well served by allowing to create these events via configuration in HA. It would mean no impact on the recorder component and it would be more flexible because you can re-map data from JSON blobs to actual columns.

@nervetattoo
For your usecase, it might be worth having a look at Custom component: Long Time State Storage (LTSS) utilizing TimescaleDB