Je m’incruste :
Quel config.yaml ?
Et dans le configuration du dossier config, je n’ai pas de ligne à ce sujet
ça depends de la structure mais chez moi :
configuration.yaml
recorder: !include yaml/recorder.yaml
et dans yaml/recorder.yaml
purge_keep_days: 7
auto_purge: true
commit_interval: 15
include:
domains:
- binary_sensor
- climate
- light
- person
.......etc....
Donc tu n’as que la config par défaut
1 « J'aime »
Alors j’ai le sensor suivant en exemple : sensor.time_date qui est présent 5139 fois
Mon recoder était en package et je viens de le remettre dans le fichier configuration.yaml pour être certain de la bonne prise en compte
C’est le fichier de base de configuration de HA configuration.yaml
Je pensais naïvement que le fait d’avoir créé le service suffisait
Bonsoir,
Juste une question complémentaire :
J’ai un historique de 7j, ma base ne dépasse jamais 500 Mo, si j’ajoute un exclude pour un capteur, j’imagine qu’il faudra attendre 7j pour qu’il n’y ait plus trace de lui dans la base ?
Bob
C’est ce que j’imagine aussi @Bob
Mais je pensais que en purge forcée, plus repack plus apply filter cela forçait les choses !!
Après j’ai aussi la table statistics qui est pleine de truc que je ne veux plus je suis certain
Je n’ai jamais utilisé apply filter pour la purge.
Ma base n’a « explosée » en taille qu’une fois, avec le test d’un MPU6050A Gyroscope / Accéléromètre sur ESP32 et une acquisition toutes les 500ms 
C’est sur ma base influxDB qu’il me reste un peu de paramétrage à faire mais c’est raisonnable, elle fait 600Mo.
Bob
Tu es sous SQLite de HA ou MariaDB ?
On peut faire entity_globs: dans les includes j’ai l’impression que cela va être plus rapide mais d’un autre coté je ne veux surtout pas perdre la partie panneau solaire dans le dahsbord energy
Mais j’ai quand même un gros paquet d’entités 
Oui j’utilise ce type de synthaxe avec SQLite:
exclude:
entity_globs:
- sensor.*battery_level*
Bob
Je pensais pareille, mais j’ai l’impression que le repack est pas complet et qui reste toujours des traces et qui faut attendre le repack_auto le deuxieme dimanche du mois pour que ca diminue vraiment la DB. Après je me trompe peu être.
@WarC0zes oui je crois qu’il faut que je prenne ma pilule de patience c’est moche ça
Un ré pack complet et purge en profondeur à lancer la nuit aurait été cool pour vomir les effet et les bien fait de mon recorder
En tout cas j’ai une multitude de sensor dans la partie outils développement > statistiques en mode corriger mais je n’ai pas le choix que des les laisser car juste un bouton OK à la fin d’un message comme quoi j’ai supprimé le truc via recorder. C’est déjà bon signe
Après échange avec d’autres utilisateurs aussi, il faut certainement que je passe sur mes entités pour simplement les désactiver car je n’en n’aurais pas besoin par exemple.
Dans ce cas pas besoin de les ajouter dans le recorder ! Cela va disparaître tout seul au bout de la fin de rétention de la donnée que j’ai mis dans le recorder
Oui, c’est ce que j’ai fait désactiver au maximum les entités qui m’intéresse pas. C’est déjà ca en moins a rajouter dans le recoder 
Encore il ont fait des efforts, mais il y a un ans de ca, tu installer une intégration ( genre pour un routeur ) et tu avait une centaines d’entités activer par défaut. La prise de tête as tout désactiver car les 3/4 servaient a rien.
Maintenant les intégrations active le minimum utile et a toi a en activer si besoin.
J’ai commencé le travail
2300 entités dont 1200 désactivé cela laisse la place à quelques heures de choix pour désactiver ça 
1 « J'aime »
Bonsoir
Alors quelques nouvelles autour d’un régime et d’un travail de fond entrepris sur le sujet de ma BDD. Un juste retour à tous ceux qui m’ont donné, exposé, aiguillé sur des pistes, solutions ou autres.
Pour fixer les esprits à tous ceux qui découvre le sujet.
Je dispose de 200 devices zigbee via Zigbee2mqtt, de 30 devices zwave via zwavejs-UI, 20 devices BT sous OpenMqttGateway (7 antennes) et sous espresence (3 antennes), 6 Shelly (EM et plug S) sans compter les autres intégrations pour enphase, netatmo, freebox etc…
C’est pas une installation énorme mais déjà bien dense tout de même avec pas loin de 3500 entités
A mon arrivée sous HA en provenance de Jeedom, je ne me suis pas du tout attardé sur la partie stockage en base de données, historique court ou terme !
Ce sujet est assez bien géré chez Jeedom en transparence de l’utilisateur qui décide juste de stocker ou non mais gare à trop stocker quand même
Bref sous HA c’est pas la même histoire ! Et il faut vraiment d’en occuper le plus rapidement possible car cela permet déjà de ne pas agir dans l’urgence sans réfléchir et sans savoir. Le fait d’avoir une base de donnée pas trop importante permet aussi de laisser un peu de vélocité à HA ce qui n‘est pas sans me satisfaire sur les ressources de ma VM.
Avant de décider de garder des données, il faut se poser la question si les entités que nous avons seront utiles ou pas ? Si inutile à court ou long terme alors il faut les désactiver dans HA mais si on peut en amont c’est mieux aussi.
A ce jeu là, j’ai supprimé pas mal d’entité pour arriver à environ 1300 entités encore vivante
Dans ces entités, il faut ensuite se poser la question : ai je besoin de voir un graphe sur mon Dashboard, ou bien de connaître un état sur le long terme ou bien sur un court terme pour faire des test.
Une fois les idées à peu près clair sur le sujet, il faut bien remplir son recoder sur la partie exclude surtout. Je me pose la question de dire j’exclue tout et par contre j’inclue que les entités souhaitées de cette manière pas de place au doute il n’y aura pas d’entité perdue qui sera enregistrée !
Pour ma part en dehors de quelques entités de monitoring, mes températures, humidités, quelques états binaires je ne garde rien d’autres dans HA (enfin presque travaux encore en cours).
Il me reste encore tout le sujet des consommations long terme que je garde pour le moment mais qui partira bientôt sur une base temporelle InfluxDB et me permettra de voir les évolutions année par année.
Je suis donc partie de 7,5Go pour atterrir à 700Mo sur 3 jours tout même.
Je me suis rendu compte que je générais quand même 200Mo de données par jour 
(merci à mes 50 prises connectées nécessaire à un bon maillage dans une maison mâchefer)
J’ai lu aussi qu’être sous MariaDB était miraculeux et que l’on gagnait aussi en taille par rapport à SQLite la base par défaut d’HA !
je me suis donc lancé dans la migration de base de données. Après quelques heures de lecture, recherche, je me lance dans la migration et 20 minutes plus tard mon HA est sous MariaDB depuis 24h déjà sans soucis apparent.
Par contre au niveau taille c’est pas la grande différence tout de même : on divise pas par 10 la taille non plus bref en 24h je pense que j’ai généré 20Mo de moins peut être et encore.
Je me pose la question de la bascule sur mon HA de prod pour le coup ou bien alors c’est pour externaliser ma base de données et travailler le sujet de manière différente mais là c’est plus pour les débutants que je suis.
Bon je m’arrête là car c’est déjà bien long mais un gros résumé de quelques jours de travail sur la BDD de HA.
C’est pas une vérité, mais mon vécu avec mes compétences et déboire de novice. Donc tout est perfectible sans aucun soucis.
Juste un partage d’expérience
5 « J'aime »
La bascule sous MariaDb m’intéresse, tu pourrais détailler le modop, s’il te plaît ?
Merci à toi pour ce retour.
J’ai eu des soucis similaires par le passé (et je suis également ancien jeedomien).
Peut être quelques compléments de mon expérience perso si cela t’intéresse:
- J’ai constaté que mettre plus de jours de rétention de données n’engendre pas une forcément augmentation de la bdd dans la même proportion (pour ma part du moins). Au départ j’étais à 2j, puis je suis passé à 7j, de mémoire j’ai augmenté la taille de la bdd que de 50%.
- Dans les backups, la bdd prends bcp moins de place. Actuellement j’ai une bdd de 750m, alors que dans le backup elle représente que 300m (je ne sais pas si cela joue, mais je suis sous mariadb aussi).
- Pour identifier les entités les plus lourdes en bdd (en occurrences du moins), sous phpmyadmin, j’ai utilisé la requête:
select entity_id, count(*) as cnt from states group by entity_id order by cnt desc;. - Certains capteurs ont des remontés très très fréquentes, avec l’impossibilité de réduire le délais entre 2 mesures. Pour palier à cela, j’ai exclu ces entités dans le recorder, mais pour avoir tout de même les données sauvegardés, alors je crée a chaque fois une nouvelle entité via « filter », avec un délais plus long. Par exemple, je n’ai pas besoin de garder le températures CPU ou bien les taux d’humidité à la seconde, dans certains cas 30 secondes, ou même 5 minutes suffisent largement.
- Au départ j’ai mis bcp trop de choses dans influxdb, puis a son tour la base à commencé à exploser. Il est donc bien important d’y mettre vraiment que les choses utiles (en plus purger influxdb est compliqué, j’ai pour ma part terminé par supprimer la base et repartir de 0). Remarque: je n’ai pour le moment pas trouvé de moyen « simple » de visualiser les données dans mes dashboard avec le même visuel que les graphes HA, mais ça fait un moment que je n’ai pas regardé (j’ai bien testé grafana, mais c’est galère quand on est pas en local, et dans tous les cas ce n’est pas les même visuels graphiquement que les graphes HA, sinon j’ai aussi utilisé apexcharts en faisant une query sur influxdb, mais ça reste compliqué)
1 « J'aime »
Un grand merci pour ce retour complémentaire c’est top
Merci pour la requête SQL que j’ai utilisé effectivement pour m’aider
Je ne connais pas encore la création d’entité filter pour réduire la fréquence des mesures (ou je connais mais je ne savais pas comment cela se nommait)
InfluxDB est au commencement de mon travail donc je vais découvrir les 1ère recommandation
Salut
Pour confirmer ce point il faut attendre 7J (remplissage)+7J(pour passer toutes les purges)
Un backup, c’est principalement du texte, donc avec un taux de compression performant… Mariadb ou sqlite ça n’a pas d’impact
Je viens de le décrire là : Migration BDD SQLite vers MariaDB
Pour ne pas encombrer ce poste qui n’a finalement pas de lien vraiment avec la manip c’est juste un déclencheur
1 « J'aime »
Bonjour,
Tu aurais un exemple de configuration filter pour un capteur d’humidité ?