Purge de la base de donnees HA

est il possible de purger d’un coup plusieurs entités ayant la même syntaxe, je m’explique :

voici 3 de mes entités :

sensor.sonoff_1000bd9abe_voltage
sensor.sonoff_1000fcfd9e_voltage
sensor.sonoff_1000fd0e93_voltage

  1. Est il possible de lister un truc du style : sensor.sonoff_*_voltage
  2. Comment savoir à quel domaine ces entités appartiennent ? car j’ai vu qu’on pouvait nommer des domaines

J’ai 432 entités actives , et c’est un poil fastidieux de les nommer une par une …

Afin de vous donner un max d’infos , voici mon fichier recorder.yaml :

################################### 
##### PURGE BASE DE DONNEES #######
###################################     
auto_purge: true
purge_keep_days: 60

exclude: # tous les éléments listé ci-dessous ne seront pas conservés
  domains: # filtrage par domaine
    - automation
    - alarm_control_panel
    - calendar
    - climate
    - group
    - media_player
    - proximity
    - scene
    - script
    - sun
    - timer
    - weather
    - zone
    - light
    - cover
    - switch
    - camera
    
    
  event_types: # filtrage par evenements
    - automation_triggered
    - script_started
    - service_registered
    - home_assistant_start
    - home_assistant_stop
    - call_service
    
  entities: # filtrage par entités spécifiques
    - sun.sun 
    - sensor.last_boot
    - sensor.date
    - sensor.time  
    - camera.192_168_1_200
    - camera.192_168_1_201    
    - camera.192_168_1_202
    - camera.192_168_1_203
    - camera.192_168_1_204
    - camera.front_door_camera
    - device_tracker 
    - person
    - sensor.sonoff_1000fd09b5_power    #Cumulus
    - sensor.sonoff_1000fd09b5_current
    - sensor.sonoff_1000fd09b5_voltage
    - sensor.sonoff_1000e7dc7f_power    #Cuisine
    - sensor.sonoff_1000e7dc7f_voltage
    - sensor.sonoff_1000e7dc7f_current
    - sensor.sonoff_1000fcfd9e_power    #Gainable
    - sensor.sonoff_1000fcfd9e_current
    - sensor.sonoff_1000fcfd9e_voltage
    - sensor.sonoff_1000fd0e93_power    #Electrovanne exterieure
    - sensor.sonoff_1000fd0e93_current
    - sensor.sonoff_1000fd0e93_voltage
    - sensor.sonoff_1000ae73b2_power    #Lumière buffet katy
    - sensor.sonoff_1000ae73b2_current
    - sensor.sonoff_1000ae73b2_voltage
    - sensor.sonoff_1000bdb28c_power    #Frigo & Dyson
    - sensor.sonoff_1000bdb28c_current
    - sensor.sonoff_1000bdb28c_voltage
    - sensor.sonoff_1000fd0bbf_power    #Clim Bosch
    - sensor.sonoff_1000fd0bbf_current
    - sensor.sonoff_1000fd0bbf_voltage
    - sensor.lixee_adps                 #lixee
    - sensor.lixee_current_tarif
    
    
    
    
    
include:
  domains:  # tous les éléments listé ci-dessous seront conservés
    - sensor
    - input_boolean
    - input_datetime
    - input_number
    - input_select
    - input_text
    - binary_sensor
    - sensor.yearly_energy_peak
    - sensor.daily_energy_peak
    - sensor.monthly_energy_peak
    

Avec les exemples proposer dans le post, ta pas vu entity_globs:

entity_globs list (optional)

Exclude all entities matching a listed pattern from recordings (e.g., sensor.weather_*).

Mea culpa Gizmos, là j’ai aucune excuse !! :zipper_mouth_face:

merci bcp pour ta réponse .

1 « J'aime »

bonjour , est ce que ce code est toujours valable ?
ma base fait 17go , et je commence a me trouver a l etroit sur mon SSD ( 60go )

j essaye de lancer ce code via sqlite , mais j ai pas de resultat ( direct un ecran noir )

Bonjour,
Oui la commande est toujours valable. Mais avec une db de 17Go, ca doit mouliner.

1 « J'aime »

Aucune raison qu’il ne le soit plus, c’est du SQL…

bon ca me fait planter le plugin sqlite …

je vais voir pour l exporter sur un pc et le traiter en local

2 « J'aime »

Il y a un souci avec l’addon SQLite Web pour le moment

j ai trouvé mon fautif …

image

0xa4c… il s agit du capteur mesurant le courant en sortie de compteur et en sortie de panneaux solaires , pourtant il est en update toutes les 10 secondes …
par contre 2002292 valeurs toutes les 10s c est 231j hors mon recorder est configuré sur 31j comment expliquer qu il y ait autant de valeurs ?

Depuis l’addon, le champ pour passer la commande est complétement buggé.
Il faut utiliser la query en ligne et non par paragraphe.


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;
1 « J'aime »

meme sur une seule ligne, des que je clique execute, ecran noir …

pas grave, j ai pu exporter ma base et la traiter depuis un ordi bien plus puissant .

une idée pourquoi mon capteur as autant de valeurs ? est ce qu il y a un moyen de purger un peu ?
est ce que les sensors qui n existent plus sont automatiquement purgés ?

17Go c est énorme et ça me bloque ( un backup complet prends 1h30 par exemple )

Salut,

Ce n’est pas qu’une question de quantité de données fournies par le capteur mais aussi un souci plus général de config. C’est pas faute de le répéter un peu partout :sleepy:

  • tu diminues le nombre de jour (10j au pire 15 maxi)
  • tu mets en place des historiques à long termes

et ça ira tout aussi bien

il faut aussi le faire sur la bonne table, par défaut c’est pas states_meta

effectivement, j etait pas sur la bonne base :slight_smile:

par contre je suis impressionné par le nombre de valeurs :

mon recorder est sur 20j , psychologiquement j ai du mal a descendre sous les 3 semaines , madame me demande souvent on avais quelle temperature le mois dernier dans cette piece ? l an dernier ( la j ai pas la réponse ).

tu parle de mettre des historiques a long terme, c est peut etre ça qu il me faut …
tu peux m aiguiller ? ( est graphana ? ou rien a voir ? )

1 « J'aime »

C’est un bon exemple !
As-tu besoin d’avoir la valeur de la température suivant:

  • 17h12 ? (1 valeur par minute)
  • en moyenne entre 17 et 18H ? (1 valeur par heure)
  • le min/max/moy sur la journée… (3 valeurs par jour)

sur 3 mois, on fait varier la quantité de données :

  • 131400 valeurs
  • 2190 valeurs
  • 270 valeurs (avec 30j/mois)

Et c’est exactement pareil pour ta conso/puissance/production…

et

je vais regarder ça ( ce soir, boulot là ) mais pour moi , avoir une valeur toutes les 5 min sur les dernieres 24h , une moyenne toutes les 15 min sur les derniers jours , une moyenne par heure sur les dernieres semaines, je pense que c est largement suffisant .

Donc tu es tout à fait dans l’objectif, même s’il n’y a que 2 niveaux

  • Une premier partie de données avec une bonne précision : données brutes sur la durée du recorder
  • Le reste des données ‹ expurgées › sans limite de durée

En complément, les données qui n’ont pas besoin de rentrer dans la base, sont éliminées dès le début

C’est fort intéressent ce que tu montre la @Pulpy-Luke

Peux tu montrer un exemple en yaml de sensor pour que le statistique long terme fonctionne

La plupart du temps il n’y a rien à faire.
Typiquement un capteur de température avec state_class: measurement c’est fonctionnel directement.


Sinon il suffit de l’ajouter (il faut faire attention aux types que l’on veut définir, notamment pour les reset)

- platform: rest
  name: Loire Hauteur Orléans
  scan_interval: 3600
  resource: https://hubeau.eaufrance.fr/api/v1/hydrometrie/observations_tr?code_entite=K435001020&size=1&pretty&grandeur_hydro=H&fields=date_obs,resultat_obs,continuite_obs_hydro
  value_template: "{{ ((value_json['data'][0]['resultat_obs']) | int(default=0)/ 1000 | round(3) ) }}" # mm en m
  unit_of_measurement: "m"
  state_class: "measurement"

L’important ensuite c’est d’utiliser une carte qui puisse afficher les valeurs à longs termes
Une vue sur 6 mois ne donne rien sur mini-graph mais sur history-explorer-cardc’est exploitable

2 « J'aime »

Merci pour ton retour @Pulpy-Luke :+1:

j ai pas encore tout pigé, ( je dois relire plusieures fois ) mais effectivement, merci pour les explications :slight_smile:
je vais essayer de mettre ça en pratique

par contre question con mais ayant 20j de purge sur le recorder, est ce normal que la db fasse 17go ?
j enregistre pas tout en + …