Split Long Term statistics into its own DB

We see posts from users quite often saying that their HA db has been corrupted. the only solution is to delete it and start over.

But it’s my understanding (at least I think since long term stats are a big black box with little info on how it works) that when that db gets re-initialized that all LT stats are gone as well.

If it was split away from the usual db and put into it’s own then the chances of it being corrupted by a corruption of the regular db are minimized. Which allows us to minimize the chance of losing that data along with all of the short term data.

That would also allow us to see an issue with the db size to then allow us to make better decisions on recorder config. As it is now I have no idea if the recent continuing growth I’m seeing in my db is from the LT stats or an issue with my recorder settings or both.

And while we are at it we might as well get a few more config options for long term stats so we have more control over the db size, location, etc.

At the risk of asking a dumb question, how do you define “long term stats?”

I mean, unless you take other action every event and state change is recorded in the database for the default retention period. Maybe there’s another category of data that I’m not aware of?

I’d vote for any improvement of recorder. That’s so poorly implemented that it reflects badly on the rest of HA. Personally I think the retention period should be settable for every entity, right in the GUI. But again, any improvement to recorder is welcome.

Statistics - basically all the new energy stuff, and now pretty much any sensor that returns a numerical value, are now stored long term so you will be able to access for example the average temperature for September 2021, in 3 years time.

Ahh, thanks. I haven’t had a chance to get into the energy stuff yet because I was stuck at an old version for a while.

On a similar subject, I have a feature request out there asking that it be possible/encouraged to set the retention period for each entity in the GUI, rather than the convoluted process now needed to exclude individual entities. This type of issue keeps coming up; I just wrote almost the same thing over on another thread. Seems like there is a lot of interest in improving recorder. Maybe more up votes for this and other such FRs would help bring some focus.

It’s not only energy stuff. It has recently become that almost all sensors now continuously write an abbreviated synopsis update to the long term portion of the db every hour.

you have zero control over what gets saved, where and for for how long the data is kept.

1 Like

Wow, you’re right. I just updated from 7.4 to 10.6 and my database has grown by 50% already, after remaining steady for months.

This is a real black eye for HA. I’d be embarrassed of the whole recorder fiasco if I were on the development team.

1 Like