Taille excessive de la base de donnée

Hello
J’ai une VM sur freebox delta avec 3/4 cpteurs pour mailler et une zlinky+ conbee
J’ai bie reussi a configurer le dashbord energy

Souhaitant m’amuser, comprendre j’ai cree des sensor energy daily monthly et yearly pour chaque couleur de mon tarif tempo
Puis des templates pour additionner ces valeurs.

Resultat en 3 mois j’ai une base de donnees qui atteint aujourd hui au bout de 4 mois 20go…

Du coup backups difficiles a cree et a sauvegarder

J’ai faux ou a votre avis?

mERCI

Salut,
tu ne fais pas dans la dentelle !!!
En 3 mois avec 5 devices, arriver à avoir une BDD de 20 Go .
Là je dis Gif Bravo Clap Clap

Sinon, tu peux regarder la configuration recorder pour avoir une BDD plus légère.

4 « J'aime »

Salut.
C’est pas les stats qui polluent ta base mais probablement une durée de rétention trop importante

1 « J'aime »

Va falloir que j potassé ces histoires de rétention alors…
Des pistes ?

Commence à partager comment t’as définié ton recorder
p.e. j’ai ça dans mon configuration.yaml (pjuste comme exemple)

recorder:
  db_url: !secret db_url
  purge_keep_days: 10
  exclude:
    domains:
      - camera
      - device_tracker
...
    event_types:
      - call_service
    entity_globs:
      - sensor.neufbox_*
      - sensor.desktop_*received
      - sensor.desktop_*sent
...
    entities:
      - sensor.linky_current_tarif
      - sensor.linky_iinst
...

Alors comment dire j’ai pas du tout défini de recorder… donc ca doit eneregistrer tout en permannence, surtout mes daily monthy et yearly etc

Vais je pour pouvoir purger ma base de données?
Après je me suis peut etre engagee dans une fausse piste avec mes sensor energy…

FAut du coup que j’etudie cette histoire de recorder. Venant de domoticz je me suis jamais posé ce genre de question…

Merci pour le coup de main

J’ai trouvé plus fort que moi en BDD :slight_smile: @fredarro
Il y a des chances quand même pour repartir propre qu’il faille faire un raz de la BDD car malgré les recorder et autres astuces il reste des traces.

Je viens d’en faire l’expérience il y a quelques semaines.
Erreur de manip sur une requête SQL qui au final m’a fait gagner 500Mo sur ma BDD de 2,5Go (201 devices zigbee dont 81 routeur en prise suivi conso et 40 Zwaves dont 12 prises suivi conso ce qui est le plus gourmant chez moi en BDD)

2 « J'aime »

Et oui, la tienne est toute petite à coté de celle de @samourai47 !
:face_with_hand_over_mouth:

Salut,
si tu n’as pas touché au recorder la durée de retention par défaut c’est 10 jours.

Les sensors untiliy_meter yearly, monthly, daily a eux seuls ne devraient pas générer 20go de données… même si tu en as 6 de chaque.

Il doit y avoir autre chose…

Aussi, effectivement HA et Domoticz n’ont pas du tout la même approche sur le contenu historique. Et a part les données statistiques de la partie Energie, HA ne garde rien.

1 « J'aime »

Bonjour,
comme le dit @AlexHass , 10 jours de rétention ( config du recorder par defaut ) avec le peu d’entité c’est pas possible en 4mois.

Faudrait vérifier sur ta base de donnée, les entités qui consomment le plus de place.
Avec DB Browser for SQLite (sqlitebrowser.org) pour installer sur pc
ou avec l’addon HA Sqlite web addon

la commande pour trouvé les 20 entités les plus gourmande:

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;

Avec DB Browser for SQLite, tu copie ta DB home-assistant_v2.db ( 20go ) sur ton pc.
tu lance DB Browser for SQLite, tu ouvre ta DB et va dans l’onglet Exécuter le SQL.

3 « J'aime »

Super avant de tout refaire je vais pourvoir comprendre et corriger
Voicic ce que donne les 50 premiers enregistrements. Ils correspondent tous a ceux du sensor lixee que je n’ai pas crée (ouf)… mais qui se creent seuls lors de l’installation

Du coup que faire… lol

Merci

Les mettre en exclusion dans le fichier recorder ?

C est une possibilité, mais ceux qui utilisent lixee ont le même soucis?

J’ai désactivé plusieurs de linky.lixee car 100% inutil pour moi, le reste exclue

    entities:
      - sensor.linky_current_tarif
      - sensor.linky_iinst
      - sensor.linky_imax
      - sensor.linky_isousc
      - sensor.linky_last_seen
      - sensor.linky_meter_serial_number     
      - sensor.linky_adps
      - sensor.linky_active_register_tier_delivered

365.000 lignes par entité du Lixee ça me parait « possible »
En partant par défaut que c’est 10 jours.
365 000 / 10 / 24 / 60 = 25
25 enregistrement par minute… toutes les 2,5 sec…

Ca fait assurément beaucoup. Je ne sais pas si ça fait 20Go bcp.
Le volume en ko occupé par une ligne est assez réduit dans la version de la base actuelle.

En tous ca si c’est les données de lixee qui sont responsables, une début serait de brider ça, c’est possible dans la config je crois.
Passer de un message toutes les 2 sec à toutes les 10 ou 15 sec c’est déjà pas mal.

Une solution que j’ai utilisé pour une prise shelly qui m’envoyait des infos toutes les 3 sec, c’est un filtre en mode « time throttle », qui enregistre qu’une valeur toutes les minutes, ce qui permet de n’avoir qu’une entrée historique par minute. Mais tout en gardant une valeur de conso toutes les 3 sec.

Il va aussi falloir que je me penche sur le problème :
image

Alors dans les parametres specifiques de z2mqtt il y a ecrit

measurement_poll_interval

This device does not support reporting electric measurements so it is polled instead. The default poll interval is 60 seconds, set to -1 to disable.

Donc comme j’ai laissé commec ca et comme tout le monde surement c’est une mesure par minute

Bonjour @samourai47 ,
regarde ce post Z2M comment filtrer les messages envoyer (attribut)?

j’ai de quoi potasser…

Merci pour ces liens et infos…