Le recorder c’est fait pour les données « volatiles » de HA pour la domotique.
Si des choses doivent être gardées, c’est soit avec des entitiés qui enregistrent des statistiques long terme.
Soit avec une autre base de données. (Influx ou autre SQL server)
Certains de ces sensor s’enregistrent toutes les 1 sec!!
En temps normal, quand le système est stable, stocker la charge de processeur, on s’en fout un peux, je garde juste la valeur actuelle et l’historique… bah osef
Ce qui a beaucoup changé chez moi c’est cet exclude:
Regarde le lien partagé par @Pulpy-Luke ça explique comment le faire dans la db sqlite standard.
MariaDB c’est un autre serveur SQL, ce n’est pas un outil pour lire ton fichier .db.
En revanche pour revenir à ton souci clairement ton auto_purge ne marche pas.
Enlève le de la configuration déjà pour commencer, car c’est par défaut à true, tu n’en a pas besoin.
La config du recorder n’est pas si compliquée.
Sur la doc ils expliquent très précisément et simplement la logique des include/exlude dans la section « Configure Fillter »
J’étais dans le même cas que toi à un moment; très exactement les même soucis. Et c’était invivable, j’avais aussi créé des automatisations pour rebooter, vider la db et tout…
Passer sur un RPi4 peut aider, mais ça serait le même problème très rapidement.
Comme je disais, à l’époque, je suis passé de 400Mo dans la DB avec 1,2millions d’entrées (events+states) à une base de 37Mo avec 200.000 entrées (events+states) et là tu respire vraiment
Sinon autre config que tu peux essayer, ça peut aider à réduire la pression sur le système et ton SSD, si tu as beaucoup de choses qui s’enregistrent. Par défaut c’est 1sec… 20sec de lag dans l’enregistrement dans la DB ce n’est pas très grave…
Depuis j’ai considérablement augmenté le contenu et les intégrations, donc je suis à 160mo en moyenne là.
Exactement comme j’ai dit:
Analyser le contenu de la base par event_id et entity_id.
Appliquer le filtre en conséquence.
Et ça a donné le filtre que j’ai partagé. Mais ils faut voir chaque installation est différente, peut-être que tu as certains de tes sensors qui bombardent plus que d’autres
Aussi réduction à 7 jours comme tu as fait et augmentation du commit interval, je ne sais pas si ça a une influence sur la taille de la db, mais en termes de processing et I/O ça aide.
Je n’ai jamais utilisé la purge manuelle.
Mais je pense que oui faut cocher le filtre.
En revanche ça risque d’être un gros boulot pour ton RPI3.
J’y irais par étape à ta place. Fait juste avec days to keep d’abord.
Repack risque de prendre beaucoup de ressources.
Refais un 2eme passage avec repack après, si ça marche le premier.
En principe, purger ça va rien donner de plus, le filtre et le 7 jours s’appliquent déjà…
Le seul truc qui peut agir, c’est le repack : taille du fichier, mais pas directement lié au contenu
Ouais mais vu son graph de la taille de la db on dirait que ça ne purge pas en auto, ça devrait se voir toutes les nuits à 4h12… donc s’il commence par une purge avec les nouveaux paramêtres en premier, puis un repack ça pourra aider.
auto_purge boolean (optional, default: true)
Automatically purge the database every night at 04:12 local time. Purging keeps the database from growing >indefinitely, which takes up disk space and can make Home Assistant slow. If you disable auto_purge it is >recommended that you create an automation to call the recorder.purge periodically.
Possible. Sur le graphique on voit la croissance sur une journée donc purge qui marche ou pas il y quand même un truc sur ce qu’on y insére.
Et si la base est trop grosse, c’est effectivement pas impossible que la purge automatique n’aboutisse pas au déclenchement journalier.
De toute façon, le premier indice c’est avec le premier comptage