Souci je constate qu’il se rempli de plus en plus vite sans nécessairement rajouter de nouvelles intégrations
Est ce du à l’enregistrement dans la base de données de l’historique des mes capteurs, tableau énergie … ?
J’ai accès à « Studio Code Server » pour identifier les différents fichiers systèmes mais je ne sais pas identifier les fichiers responsables ? Existe t il une simple manipulation sur ces fichiers pour libérer de la place ?
Sinon j’envisageais de déplacer mon disque de donnée vers un disque SSD externe comme proposé, branché en USB, hors les 2 ports USB sont occupés (DongleZigbee + RFXCOM)
Un hub USB, avec alimentation externe, pourrait il fonctionner pour y brancher le nouveau disque de données.
Bonjour,
si tu avais lu le message quand tu crées un sujet et remplis les informations, ont aurait pu voir la taille de la DB :
Ma configuration
Texte à remplacer par votre configuration
Comment récupérer ma configuration :
Dans votre HA, Menu latéral Paramètres > Système > Corrections puis les trois petits points en haut a droite > Informations Système puis une fois en bas Copier
Dans informations système, tu verras la taille de ta DB.
Il y a de forte chance que ta DB gonfle et utilise de la place. Pour cele il faut configurer le recorder pour limité les entrées dans l’historique.
Tu peux faire une recherche sur le forum, tu trouvera plein de sujet qui en parle.
Merci pour ton lien sur Recorder que je vais lire attentivement
Cependant vais je pouvoir faire dégonfler la Data Base ?
Qu’arrive t il si j’emplafonne la limite du disque ? Plantage ou pas ?
Si le disque est plein ca va mal se passer en effet. Fais des backups et pas en local du coup.
Vérifies d’ailleurs si tu as des backups en local. C’est l’option par défaut.
merci oui j’ai effectué une sauvegarde sur mon NAS
Par manque de temps je viens de parcourir en travers la doc sur Recorder j’y reviendrai plus tard
Pour stopper l’hemorragie docteur, est ce que ce code dans configuration.yaml ferait l’affaire ?
Il te manque un auto_purge: true. J’ai ça dans le mien.
Les automations et les update je ne sais pas trop pourquoi tu veux garder ça.
Tu peux limiter plus les sensors avec des lignes de ce type:
Il te faut voir, les entités qui consomment le plus avec sqlitebrowser.
Tu copies ta DB sur ton PC , lance sqlitebrowser, charge ta DB et va dans l’onglet executer le SQL.
Tu rentres ce code et exécute :
SELECT states_meta.entity_id, COUNT(*) AS count
FROM states
JOIN states_meta ON states.metadata_id = states_meta.metadata_id
GROUP BY states_meta.entity_id
ORDER BY count DESC
LIMIT 30;
Incomprehensible docteur , c’est un chirurgien qui me faut à présent
Pour Info, j’ai énormement de capteurs branchés => 70 capteurs en MQTT et 17 en RFXCOM
Citation => Tu copies ta DB sur ton PC
Question => je la trouve où ? dans studio code server ?
Sinon ok pour supprimer auto_purge: true
Merci encore WarC0zes pour ton aide, un vrai puit de connaissance
je vais tenter ce soir d’identifier le responsable avec ta manip
Cependant pourquoi l’action manuelle de purger « recorder.purge » dans outil de developpement ne purge rien chez moi ?
recorder purge permet d’effacer de la base les elements qui ne sont plus enregistrés.
Là tu n’as pas défini de filtre, il n’y a rien a purger.
Si demain tu déclare (par exemple) ne plus vouloir enregistrer les états de l’entité sun.sun, ton recorder va arrêter d’enregistrer, mais les anciens enregistrements sont toujours dans la base (ta base va donc juste « grossir moins vite »).
recorder purge te permettra alors d’effacer ces anciens enregistrements (et ta base va diminuer).
En plus de ce qui a déjà été remonté, il y a des trucs bizarres dans ta config. - sensor* bon ben là c’est large, beaucoup trop large
- sensor.date il est déjà inclus dans la partie globale (c’est un sensor aussi). Et accessoirement c’est typiquement le genre d’info dont on se fiche : as-tu vrai besoin besoin de noter quelle heure il est dans une entrée dédiée de ta base, sachant que tous les évènements sont déjà horodatés ??? Je suis sur à 200% que ça ne sert à rien. En plus c’est un truc qui est typiquement à exclure. 1 entrée par minute, ça commence à faire beaucoup sur 5 jours
- sensor.last_boot là aussi j’ai du mal à comprendre, il est déjà inclus (c’est toujours un sensor) mais son usage est discutable aussi… Avoir l’info du dernier reboot, ne nécessite pas de mettre ça en base (donc un historique), et ça ne sert à mon sens qu’en phase de débug (un souci d’alim par exemple)
Merci à vous pour l’explication dans mon cas du non effet de l’action manuelle de l’action « recorder.purge »
Sans trop abuser, pourrais tu partager ton propre filtre yaml pour que je m’en inspire et surtout pour stopper en urgence l’augmentation du volume de ma DB
Merci encore
Te partager nos filtres ne sera pas forcément utile.
Ce qu’il faut savoir c’est qu’il y a deux mécaniques:
l’ajout au recorder (la parie include)
ou tu peux ajouter des domaines, des filtres ou des entités.
la soustraction du recorder (exclude).
Ou tu peux enlever du recorder des domaines, des filtres ou des entités.
Ce qu’il faut comprendre c’est la logique. Si j’essaie de faire simple:
Si tu ne met aucun « exclude » et que tu declare des « include »:
Par défaut rien n’est enregistré, et seules les parties que tu as ajouté dans « include » sont incluses. Il te faut donc à chaque nouvelle integration réfléchir si tu veux ajouter de nouvelles entités au recorder.
Si tu inclus entité par entité ou avec un filtre bien calibré c’est la façon qui permet d’avoir une database la plus petite possible.
Si tu ajoute tout un domaine (par ex sensor ) tu te retrouve très (trop?) vite avec beaucoup d’informations, donc attention.
Si tu mets des « exclude »:
La logique s’inverse, HA part du principe que tout est inclus, puis exclue les filtres que tu a rentré dans exclude, puis inclue ce que tu déclare dans include.
Attention n’importe quelle nouvelle integration risque donc d’être enregistrée par défaut si tu ne la filtre pas
suivant les cas il est plus pratique d’exclure que d’inclure, donc a voir ce qui est plus pratique pour toi.
[edit]
Va dans HA dans parametres / appareil et integrations
et affiche la liste de toutes tes entités.
Jusqu’à présent tu enregistrait tout ça pendant 10j!
Regarde là dedans (attention il y en a peut être beaucoup) lesquelles sont intéressantes à mettre dans le recorder et a partir de ça et des logiques ci dessus, decide:
si tu les inclus une par une, ou avec un filtre
si tu préfères exclure les integrations bavardes…
etc…
Si ton installation n’est pas trop grosse, il est peut être intéressant de faire un include entité par entité, c’est ce qui te fera la DB la plus petite possible !
Merci les gars pour vos conseils, c’est beaucoup plus clair maintenant, je vais pouvoir tester différent réglages pour le filtre.
Après je suis surpris que dans une box clé en main avec un petit disque comme la Green il n’y ai pas un outil intégré sans passer par du yaml toujours délicat à manier, bref …
Dernière question sans réponse dans ce fil, concernant le hub USB (les 2 prises USB de ma box étant occupés)
Est ce qu’un hub USB avec alimentation externe permettrait de brancher un disque SSD pour être plus confortable en données disponibles ?
Jouer sur la durée de rétention uniquement, n’exclue pas la création de statistiques à long terme qui prennent de la place quand même (à un rythme inférieur cependant)
C’est tout à fait exact. Mais au moins ces stats ne concernent que les « measurements » et donc on dégage déjà beaucoup d’entités… (en tout cas chez moi)
