Purge de base de données > 7.5Go!

Excellent sujet j’adore :slight_smile:

Il va falloir poser les pierres une à une c’est cool

je viens de faire un début d’analyse de la BDD, je viens de trouver 2 ou 3 prises connectées qui sont un peu verbeuse ! Cela date d’une phase de test où je ne suis visiblement jamais revenu en arrière !
Du coup une donnée toutes les minutes.

Ensuite j’ai vu aussi que le BT sur mes nouvelles antennes ESP32 sont très verbeuse pour voir comme il faut les tag nut. A voir si je peux me dispenser d’historique ou pas dans cette phase de mise en production.

Bien sur cela changera aussi au fur et à mesure que l’on met en place le sujet transmis :slight_smile:

Question //, sur ma VM où j’ai influxDB déjà je n’ai pas telegraf (mais est-ce vraiment utile ?) mais surtout il me semble que les données sont présentes que 30 jours pas plus ensuite il faut une licence non ou j’ai pas compris ?

Ce cas là se gère assez bien. L’historique des tags tu n’en a pas besoin, par contre tu peux garder l’historique de la personne (sur laquelle un ou plusieurs tags sont associés)

telegraph c’est le buffer avant influxdb… Quant à la durée, c’est pas lié à la licence mais à la config du bucket de stockage

Ok pour la partie personne :wink: je vire le tag et je garde que la personne au sens historique

pour télégraf je ne l’ai pas et j’envoie directement sur Influx pour le coup
Je vais regarder la config Bucket pas fait attention

Je découvre des sensor en base avec un stockage important je vais leur faire la peau :rofl:

Après je passe à la méthode ciblée influxDB via Node Red pour tester et plus si affinité

Paris ne s’est pas fait en un jour alors au boulot

Edit : j’ai les Shelly EM qui sont un peu verbeux aussi en MQTT

Bon je viens de faire un test à l’instant
Création d’une nouvelle VM et mise de ma sauvegarde de cette nuit et là une belle surprise !

image

Contre
image

avec tout le ménage que j’avais pu faire des modules complémentaires que je n’utilisais pas !!

cela fait une sacré cure quand même

Bon je ne sais pas trop ce qui est parti mais bon cela fait le clair

@Pulpy-Luke je t’embête un peu encore désolé
Si j’envoie vers InfluxDB des infos aucun intérêt de les avoir aussi dans HA en plus sauf si je veux faire un Dashboard avec le sensor.
J’ai des prises Shelly Plug S (Wifi par MQTT car j’ai besoin d’un accès externe dessus) et il semble qu’elle parle beaucoup ! mais pas trouvé le moyen de les rendre moins bavarde.
Je fais des exclude en pagaille du coup en ce moment :slight_smile:

1 « J'aime »

Hello.
Oui une méthodologie qui me semble pertinente :

  • Coté influxdb, on n’envoie QUE ce qui est nécessaire pour un stockage à long terme, et qui n’est pas déjà dispo avec les stats & co de HA. Soit des donnés directement exploitables, soit celles qui sont nécessaires à des calculs (min/max etc)
  • Coté base HA, il faut se poser la question de quelles données sont utiles pour les graphs et pour quelle durée. La température des WC il y a 3 semaines, je suis pas certains que ça serve souvent par exemple.
  • Et donc quand les données ne servent pas, on les vire

Parfait, je suis en phase avec ça où à une nuance quand même c’est que dans l’immédiat je pousse un peu brutalement sur InfluxDB :slight_smile:

je range déjà ma chambre coté HA dans l’immédiat, je tente de pas mettre trop le bazar sur influxDB quand même :crazy_face:

Ensuite, je vais m’attacher une fois les deux chambre HA et influxDB au clair à voir comment je peux ajouter des données anciennes sur un bucket A d’influx à mon bucket HA fraichement mis en route, de cette manière je retrouve mon historique.

Mais nous sommes en phase aucun intérêt de stocker ni sur HA ni sur influxDB des sensor type *_power_outage_memory etc… enfin pour mon usage

Tout à fait !
Attention quand même, le nettoyage dans influxdb, c’est pas aussi facile après coup

Oui je me doute, je ne veux pas le bordel non plus dessus mais je voulais dire que je mettais plus la donnée brut que travaillée pour le moment mais pareil en tentant de pas mettre des données du type *_power_outage_memory etc…

Entre l’organisation en include, package et la BDD de données il y a des fondamentaux important à voir et à mettre en place pour les débutants sur HA à mon sens pour ne pas vivre ce que je fais à date

1 « J'aime »

J’ai encore 2,8 Millions de données dans la base HA et pourtant j’ai fait des exludes :rage: dans la tables des statistiques

Tout ça (et le reste que je n’ai pas) en tête, c’est quand même très lié à tes besoin/profil/config
Et puis au début avec une petite installation, on peut se satisfaire d’un truc ‹ pas optimal ›, quand ça commence à être plus gros, c’est moins évident.
Du coup, ça me parait vachement compliqué de répondre, mais je ne vois pas d’autres astuces pour l’instant

Regarde si les includes/excludes ne s’annulent pas mutuellement

Oui quand ça grossit il faut faire attention et avec 300 objets plus les intégrations je dois avoir pas mal de bazar dans toutes les tables

@Pulpy-Luke
Pour le moment j’ai ce format

recorder:
  purge_keep_days: 10
  auto_purge: true
  auto_repack: true
  include:
    domains:
      - binary_sensor
      - sensor
      - switch
      - person
      - device_tracker
      - light
      - select
      - plant
      - cover
  exclude:
    domains:
      - automation
      # - binary_sensor
      - bodymiscale
      - button
      - calendar
      - camera
      - climate
      # - cover
      # - device_tracker
      - group
      - input_boolean
      - input_button
      - input_datetime
      - input_number
      - input_select
      - input_text
      # - light
      - lock
      - media_player
      - number
      - openplantbook
      - persistent_notification
      #  - person
      #  - plant
      - proximity
      - remote
      - script
      # - select
      # - sensor
      - siren
      - sun
      # - switch
      - update
      - vacuum
      - water_heater
      - weather
      - zone
    event_types:
      - automation_triggered
      - script_started
      - service_registered
      - call_service
      - service_removed
      - service_executed
      - platform_discovered
      - homeassistant_start
      - homeassistant_stop
      - feedreader
      - component_loaded
      - timer_out_of_sync
    entities:
      - sun.sun
      - sensor.cpu
      - sensor.last_boot
      - sensor.internet_time
      - sensor.solar_angle
      - sensor.date_time
      - switch.pc_test


    entity_globs:
      - sensor.weather_*
      - sensor.*_uptime
      - sensor.cpu_temp*
      - sensor.time*
      - sensor.date*
      - sensor.*_tx
      - sensor.*_rx
      - sensor.*_uptime_2
      - sensor.*_tx_2
      - sensor.*_rx_2
      - sensor.*_motion
      - sensor.*_high
      - sensor.dalg_3070_*
      - sensor.dalg_win11_*
      - sensor.unifi_gateway_*
      - sensor.dalg_cam*
      - sensor.pc_test_*
      - sensor.pre_test*
      - sensor.nut_*
      - sensor.tile_*
      - sensor.myfox_*
      - sensor.pre_test*
      - sensor.pc_*_temperature
      - select.pc_*_indicator_mode
      - select.pc_*_power_outage_memory
      - select.vib_*_sensitivity
      - select.pc_test_*
      - device_tracker.broadlink*
      - update.wud_*
      - switch.pc_ch_*

et je fait du spécifique Exclude avecentity_globs:

Mais peut être qu’il faut la logique inverse j’exlu tous les sensor et je fais de l’include spécifique
Plus précis et plus radicale

Par contre dans la table states je vois des entity_id de device que je sais que je n’ai plus

Ce que j’ai est assez similaire (include sur des domains et excludes sur des entity ou entity_globs. Ce qu’il fat voir c’est quels « type » passent quand même les filtres et adapter avec un exclude par exemple.
De plus il ne faut pas oublier de faire une purge (et repack, voire restart) pour voir le résultat

Pour avoir une application direct de notre recorder on lance bien via Service ?
comme ceci par exemple

Si oui j’ai par exemple des sensor.date* qui reste c’est embêtant car j’ai mis en exlude :

entity_globs:
      - ....
      - sensor.time*
      - sensor.date*
      - ....

Un nom concret pour voir si ça matche pas avec 1 include (les regex sont traites)?
Et ton recorder est bien inclus dans le config yaml (on ne sait jamais)

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