Hello, ce code fonctionne encore car moi je n’y arrive pas
Bonjour,
oui ça fonctionne toujours.
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 20;
On s’en passer alors car moi j’ai toujours pareil
DB browser en 3.13.1 et la BD fait 4GO
Meric pour ta réponse
Merci pour la réponse
Vous la copiez comment la db ? moi je l’ai prise à la racine avec un copié /collé basique
On ne la copie pas, on va la lire dans le répertoire config en ayant activé le partage samba
Je la copie/colle en réseau avec samba share. Ma DB ne fais que 285 Mo.
Ma BDD fait 1,1Go avec 200 devices Zigbee 10 zwave un peu de BLE et tout un tas d’autres devices, template etc…
Le recorder est vraiment la pierre angulaire de la BDD
Merci pour vos réponses je vais regarder
@jerome6994 Oui mon fichier recorder est paramétré et elle fessait environ 1.2 1.4 Go et cela me convient. Mais là elle a grossi d’un coup et je pense que c’est dû à toutes les entités Frigate (frigate installé dans docker distant), mais je veux vérifier pour être sur
Edit : Je ne voie pas la différence avec une copie qui est le meme fichier mais cela fonctionne, merci. En plus rien à voir avec frigate
Bonjour
Il est fort possible
Le recorder chez moi est mis en exclusion de tout et par contre quand j’ai besoin de l’entités je l’ajoute à la mais dans l’include.
Ce qui a pour effet que la BDD ne bouge pas quand je mets de nouveaux jouets dans HA.
C’est hors sujet, mais frigate a été mis en docker distant mais sur une machine dédiée à frigate avec un boost coral ? Tu as combien de caméra dessus ?
J’hésite à franchir le cap
Oui un NUC I5 mais coral obligé sinon ce n’est pas assez stable, 7 cameras
Bonjour a tous,
J’ai également un problème similaire et je me bataille depuis plusieurs jours, mais je n’arrive pas à baisser la taille de ma DB !
Elle fait 21Go.
J’ai fait la requête pour identifier les entités importantes :
Et j’ai ajouté tout ça dans ma config recorder.
Les logs (journaux) semblent bien purgés, mais pas l’historique.
J’ai aussi purgé en manuel mon historique avec le service « purge entities » mais j’ai toujours le même nombre de lignes pour les entités en question.
Avez-vous une idée ? J’ai du mal à comprendre ce qui se passe !
Comment arriver à diminuer cette DB ?!
Hello,
Tu as une erreur dans ton entity_glob, tu as mis un tirret au lieu du point entre sensor et ticmeter
La taille de a base ne diminue pas directement après avoir purgé les entités, il faut lancer un compactage (repack) de la base (ou attendre son déclenchement automatique)
action: recorder.purge
data:
repack: true
apply_filter: false
keep_days: 10
A+
Bien vu pour cette erreur !
Merci pour ton retour rapide.
Je lance également des repack mais la taille de la DB ne change pas. Le seul truc que je remarque c’est le fhier temporaire .wal qui se régénère et se stabilise a 387Mo
Du coup je ne comprend toujours pas pourquoi ma DB fait 21Go
Y a t’il possiblement d’autres éléments a vérifier qui peuvent prendre de la place dans cette DB hormis les states ?
Salut
Tu dois vérifier que ce que tu as demandé de virer de la base en premier lieu… Donc repasse par l’étape comptage.
Bon après au niveau de la méthode quand même assez peu convaincu
- effacer 1 entité (la 4ème plus présente), ça laisse les autres dans la base, dans il ne faut pas espérer gagner à max
- passer par une automatisation plutôt que de configurer le recorder, c’est être obliger de faire le travail de nettoyage régulièrement, plutôt que de la faire 1 fois pour toutes
En regardant les entrées les plus fréquentes, avec un visualisateur ?
Bonjour,
Merci pour vos aides. Finalement c’est Ok !
J’utilise HA en docker sur un syno et ma 2nd barrette de RAM n’était plus reconnu. Après avoir rajouté de la RAM le repack c’est fait correctement. HA n’avait surement pas assez de ressource pour arriver a faire son repack donc je n’avais plus de purge depuis plusieurs semaines.
J’ai eu du mal a identifier car il n’y a pas d’erreur ou de log spécifique pour le repack, ni d’avancé en % de celui-ci