I see… Are there any reasons to use a not-default DB for an average user?
for me it’s a legacy thing…switched a few years back and have stuck here…from what I read the default SQLite DB is the way to go now if you can (no performance, reliability, etc boost from other options that may have been there previously)
1 Like
Sorry, I understood nothing from your post, my poor English probably.
Do you think that a default SQLite is worse than other solutions - or better?
Do you think that a default SQLite has become faster & more reliable than it was - or quite opposite?
no worries…my understanding is that…
- as of today default SQLite is the best DB for most HA users (and developers have put lots of work recently into making this happen)
- this may not have been the case previously (hence my use of MariaDB)
** but all just my own opinion
Has anyone tried history stats from the new UI? It seems not working. I created 2 but both show errors.
There is also no option to delete it. It just takes me back to the setup page.
Remove the quotes from around your template when using the UI.
And after removing quotes & save - wait a bit, the sensor will become “not unavailable”. In may case it was a few minutes… (ofc I pressed F5).
Note that after reopening settings (cog) for this sensor you will only have an access to the last page of the wizard (where you defined start/end), you will not be able to edit other settings. This is a bug reported in core.
Probably plotting smth against you.
1 Like
if you can, would you please add that to the issues Ive opened.
I didnt check myself yet, but will certainly do so now
is this inside the app, or your phone settings? or your bill already 
1 Like
Thank you. It worked
1 Like
Completed successfully a couple of hours after I posted, as it turns out.
(db performance is fine under normal circumstances. I suspect this is almost certainly just a product of it being non-local - my HA container runs on my k8s cluster and the db is a MariaDB instance on a shared NAS backend, so the network is occasionally a bottleneck under unusually high sustained loads.)
Anyone here can help me with the following. I have just found out my database conversion has been taking a long time because I have been collecting basically all data for the last couple of years. Now only willing to remain 90 days and keep the rest in the long storage with the less dense history etc feature.
But now I want to purge the DB but it won’t start probably due to the database alerations starting by the upgrade.
Any workarounds?
We are talking about 90+GB
Anyone else had problem with the cast service? Seems that is not more reacheble, what’s changed? I’ve opened a thread 2024.8 google cast issue - Configuration - Home Assistant Community (home-assistant.io)
So, after 24h+ of migrating it seems the process failed. Had 400 days configured resulting in a DB of about 50GB. In the end I got errors about the lock table not being large enough to do the migration. Since this apparently results in the recorder not being started I could not reduce my configured retention and do a purge. A restart of the host just resulted in the migration to restart.
I decided to just drop the DB 
. I now have 90 days configured which will hopefully prevent this in the future. It’s specifically the loss of the data in the energy dashboard that makes me sad.
With the backup of the system you may loose just a day’s worth of data.
But an import/export facility for the statistics (energy) might be very useful.
Did a restore, but after restore a lot of core component (amongst which the recorder) couldn’t start anymore.
Have the same issue as well. But with 90GB. Restore of a backup also not working
i have this issue since upgrading to 2024.8 also. I notice my IPP and Yamaha network AVR are also unavailable since the update… could it be related?
Is there a way to add labels to the badges as I have a few that are on/off in a row that have no distinction between them now!