Il n’y a probablement pas d’erreur dans ta base, mais rien que 1.3 millions d’enregistrements pour les 4 premieres entités ça commence à piquer
A toi de revoir ce que tu peux encore virer, il y a toujours plein de trucs inutiles
Et les outils de stats aident au diag
J’ai un recorder de 574j ma bdd fait 11Go, tranquille pas de problème
Mon top4 :
Dés quelle dépasse 15Go j’optimise. Le « current tarif » va bientôt sauter.
Bonsoir ça me plaît bien ces statistiques, mais je ne vois pas comment faite pour les capteurs qui viennent d’une intégration ( donc pas de yaml). Faut créer de nouveaux sensor qui ont pour valeur le sensor de l’intégration ? Ca va dupliquer les entités?
Par exemple les capteur qui viennent du rfplayer ou de mqtt ( enoceantomqtt).
Nota: actuellement je fait ça avec influxdb qui remplit des bases de donnée moyen et long terme que j’affiche après sous graphana, ça marche très bien mais ça fait usine à gaz ( je viens de domotics ça faisait tout seul le stockage long terme)
c’est souvent déjà tout fait ! Il suffit de regarder les classes
L’autre option c’est de passer par le customize.yaml pour ajouter les infos manquantes et du coup pas de duplication
C’est une autre option, mais c’est un peu lourds juste pour faire pareil que le fonctionnement de base. Tu noteras d’ailleurs que ça ressemble à domotics sur le principe quand les capteurs sont bien configurés
et il y a t- il un moyen pour avoir moins d enregistrements ?
cet apareil 0xa4c138ea17209f20 , c est une double pince tuya pour mesurer ma conso electrique et ma production solaire .
dans sa conf, c est censé faire une remontée toutes les 10 secondes .
quand je regarde avec mqtt explorer, il y a bien un update toutes les 10 secondes, mais de 13 messages ce qui explique surement 1 millons d enregistrements …
sais tu comment je peux limiter ça ?
dans le recorder , je n enregistre pour cet équipement que ça
- sensor.0xa4c138ea17209f20_energy_produced_a
- sensor.0xa4c138ea17209f20_energy_produced_b
- sensor.0xa4c138ea17209f20_power_ab
- sensor.0xa4c138ea17209f20_power_b
- sensor.0xa4c138ea17209f20_energy_b
qui me servent nottement dans le panel energy donc c est gardé en long term ?
est ce que ça vaudrait le coup de virer ces 5 entrées du recorder , et creer 5 nouveau sensor ? mais ils seront mis a jour pareil non ?
À chaque nouvelle valeur, ça fait une entrée en base. Tu n’as pas la main là dessus.
Donc si tu as 13 valeurs par sensor toutes les 10 secondes, ça fait autant d’enregistrement en base.
A mon avis il faut plutôt comprendre et corriger ce 13
Bonjour @Zekje
Je ne sais pas sur quoi tu tourne ZHA ou Z2M ?
Mais sur Z2M il doit y avoir déjà un paramètre possible qui est debonce que tu peux mettre à 1.
Et ensuite il peut y avoir une fréquence s’envoie mais pas certain car une pince c’est fait pour de la mesure fréquente.
Sur les pince Shelly je ne crois pas avoir ce paramètre faut que je contrôle dès que je suis PC
Merci de ton retour @Pulpy-Luke
Juste une question comment connaître la class d’une entité ? L’intégration que j’utilise ne le précise pas. Y a l’info qq part dans ha?
Édit : j’ai trouvé c’est dans outil de dev puis état ( faut regarder via un navigateur et non pas via l’application ha). Mais mes sensors ne sont pas de class measurement ils n’ont d’ailleurs aucune state_class, snif.
Je vais passe via constumize.yaml
je suis en Z2M
j ai mis le debounce a 1 sur ce periph , je veais ce soir ( avec mqtt explorer ) si ca permet de virer les 13 enregistrements simultanés ( en théorie c est a ça que ça sert )
un petit update , commençant a manquer de place sur mon HA , j ai fait du ménage au niveau linux et dégagé une 20 aine de go ( sur un disque de 60 ca compte ) je sais pas pourquoi mais j avais des repertoires temporaires ( dans /tmp ) avec des copies de HA et ofrcement avec des copies pas trop grosses de la db … j ai tout viré et pas de soucis.
j avais tenté un .dump depuis un pc , mais le fichier généré (qui etait descendu a 6go ) et pris comme une base corrompue … domage, meme un PRAGMA check ne trouvant pas d erreur
bref, avec un peu plus de place pour respirer , je pense que le purge/repack a pu se faire, je suis passé sans trop savoir pourquoi de 18 à 5go , ce qui me parrait plus ‹ normal › ( mais j avais configuré 7j de rétention )
Je viens de le remettre a 30j , verdict dans un mois savoir si elle as de nouveau enflée ou pas
Mouais
Si 7j => 5Go alors ça peu aller jusqu’à 30j => ~20Go
15Go pour l’OS, 20Go pour la base, (sans compter les backup) tu attaques bien ton quota sur un disque de 60Go
Salut à tous ,
je me bagarre encore avec la taille de ma base , je n’arrive pas à purger efficacement .
Voici le detail de mon code :
declaration dans configuration.yaml du fichier recorder.yaml :
########################################
##### AJOUT RESOURCES DIRECTORIES ######
########################################
automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
command_line: !include command_line.yaml
sensor: !include sensors.yaml
binary_sensor: !include binary_sensors.yaml
utility_meter: !include utility_meter.yaml
recorder: !include recorder.yaml
Normalement ça c’est bon !
ensuite dans mon recorder.yaml :
###################################
##### PURGE BASE DE DONNEES #######
###################################
recorder:
auto_purge: true
auto_repack: true
purge_keep_days: 30
commit_interval: 60
exclude: # tous les éléments listés ci-dessous ne seront pas conservés
domains: # filtrage par domaine
#
# - alarm_control_panel
# - automation
# - binary_sensor
# - button
# - calendar
# - camera
# - climate
# - cover
- device_tracker
# - input_number
# - light
- media_player
- uptime
# - number
# - person
# - plant
# - proximity
# - remote
# - scene
# - select
# - sensor
# - sun
# - switch
# - update
# - weather
# - zone
# event_types: # filtrage par evenements
# - automation_triggered
# - script_started
# - service_registered
# - home_assistant_start
# - home_assistant_stop
# - call_service
#
entity_globs: # filtrage par entités similaires
- sensor.x50_*
- sensor.station_*
- sensor.time_*
- sensor.date_*
- sensor.*_last_seen
- sensor.*_threshold
- sensor.*power
- switch.disjoncteur_*_breaker
- number.disjoncteur_*_threshold
- sensor.lixee_*
# - sensor.sonoff_*_voltage
# - sensor.sonoff_*_power
# - sensor.sonoff*_current
# - sensor.ble_illuminance_*
# - sensor.ble_conductivity_*
# - sensor.ble_moisture_*
# - sensor.ble_temperature_*
# - sensor.capteur_*_temperature
# - sensor.capteur_*_humidity
# - sensor.capteur_*_battery
#
entities: # filtrage par entités spécifiques
- sensor.last_boot
- sensor.processor_temperature
- binary_sensor.ble_toothbrush_oral_b_katy
- sensor.memory_use_percent
- sensor.disjoncteur_prises_temperature
- sensor.processor_use
- sensor.sonoff_1000fd09b5_power
- sensor.sonoff_1000e7dc7f_power
- sensor.home_assistant_v2_db_size
# - 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
# - sensor.lixee_adps #lixee
# - sensor.lixee_current_tarif
# - sensor.sun_solar_azimuth
# - sensor.sun_solar_elevation
#
#
#include:
# domains: # tous les éléments listés ci-dessous seront conservés 30j
# - person
# - sun
# - zone
# - binary_sensor
# - cover
# - button
# - calendar
# - device_tracker
# - switch
# - climate
# - number
# - alarm_control_panel
# - camera
# - input_boolean
# - input_datetime
# - input_number
# - input_select
# - input_text
# entity_globs: # filtrage par entités similaires
# - sensor.sonoff_*_power
# - sensor.ble_illuminance_*
# - sensor.ble_conductivity_*
# - sensor.ble_moisture_*
# - sensor.ble_temperature_*
# - sensor.capteur_*_temperature
# - sensor.capteur_*_humidity
# - sensor.capteur_*_battery
# - sensor.sonoff_*_energy
# - sensor.processor_use
# - sensor.conso_energie_watts
# - sensor.sonoff_*_energy
# - sensor.*_energy_peak
# - sensor.lixee_*
# - sensor.*_base_cost
# - sensor.prix_*
# - sensor.*_energy_cost
# - sensor.*_energy_cost_2
# - sensor.*_cost_peak
# - sensor.foobot_*
# - sensor.disk_*
# - sensor.memory_*
# - sensor.processor_*
# - sensor.prise_*_energy
# - sensor.prise_*_power
# - sensor.speedtest_*
# - sensor.disjoncteur_*
# entities: # filtrage par entités spécifiques
# - sensor.capteur_de_luminosite_aqara_illuminance_lux
# - sensor.conso_kwh_prise_ordi
# - sensor.conso_kwh_pdg_exterieur
# - sensor.conso_journaliere_maison
#syntaxes pour voir la base :
# pour DB Browser :
# 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 100;
# pour SQLite web :
# 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 100;
malgré cela j’ai encore une bdd de 3,5Go , ok je garde 30 jours mais j’ai pas bcp de capteurs me semble t il …
Quand je regarde la bdd avec sqlite web et la bonne syntaxe :
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 100;
voici le resultat :
sensor.sonoff_1000fd09b5_power | 445028 |
---|---|
sensor.sonoff_1000fcfd9e_power | 372194 |
sensor.sonoff_1000e7dc7f_power | 350513 |
sensor.sonoff_1000fd0bbf_power | 243673 |
sensor.sonoff_1000fcfa16_power | 193490 |
sensor.memory_use | 169705 |
sensor.memory_free | 169688 |
sensor.sonoff_1000fd0e93_power | 165085 |
sensor.sonoff_1000bd9abe_power | 159450 |
sensor.sonoff_1000bdb28c_power | 155940 |
sensor.sonoff_1000ae73b2_power | 155431 |
sensor.sonoff_1000e7de36_power | 137731 |
sensor.sonoff_1000bd9b3b_power | 136234 |
sensor.memory_use_percent | 118443 |
sensor.lixee_papp | 112092 |
sensor.lixee_last_seen | 112092 |
sensor.lixee_iinst | 112092 |
sensor.lixee_current_tarif | 112092 |
sensor.lixee_base | 112092 |
sensor.lixee_adps | 112092 |
sensor.conso_energie_watts | 111012 |
sensor.capteur_soufflage_clim_temperature | 92070 |
sensor.capteur_soufflage_clim_humidity | 92070 |
sensor.capteur_soufflage_clim_battery | 92070 |
switch.disjoncteur_prises_under_voltage_breaker | 58413 |
— | — |
switch.disjoncteur_prises_temperature_breaker | 58413 |
switch.disjoncteur_prises_power_breaker | 58413 |
switch.disjoncteur_prises_over_voltage_breaker | 58413 |
switch.disjoncteur_prises_over_current_breaker | 58413 |
switch.disjoncteur_prises | 58413 |
sensor.disjoncteur_prises_power | 58413 |
sensor.disjoncteur_prises_last_seen | 58413 |
sensor.disjoncteur_prises_energy | 58413 |
number.disjoncteur_prises_under_voltage_threshold | 58413 |
number.disjoncteur_prises_temperature_threshold | 58413 |
number.disjoncteur_prises_power_threshold | 58413 |
number.disjoncteur_prises_over_voltage_threshold | 58413 |
number.disjoncteur_prises_over_current_threshold | 58413 |
sensor.disjoncteur_prises_temperature | 55690 |
switch.prise_machine_a_laver_le_linge | 52955 |
sensor.prise_machine_a_laver_le_linge_power | 52943 |
sensor.prise_machine_a_laver_le_linge_energy | 52943 |
binary_sensor.livebox_fibre_wan_status | 42087 |
sensor.ble_moisture_5c857eb0c7bb | 41482 |
sensor.ble_temperature_5c857eb0c7bb | 41407 |
sensor.ble_illuminance_5c857eb0c5f5 | 41366 |
sensor.ble_illuminance_5c857eb0c7bb | 41340 |
sensor.ble_conductivity_5c857eb0c7bb | 41333 |
sensor.ble_moisture_5c857eb0c5f5 | 41330 |
sensor.ble_temperature_5c857eb0c5f5 | 41313 |
sensor.ble_illuminance_capteur_pied_elephant | 41301 |
sensor.ble_moisture_capteur_pied_elephant | 41297 |
sensor.ble_temperature_capteur_pied_elephant | 41290 |
sensor.ble_conductivity_capteur_pied_elephant | 41285 |
sensor.ble_conductivity_5c857eb0c5f5 | 41239 |
sensor.ble_moisture_5c857eb0c9a2 | 40855 |
sensor.ble_temperature_5c857eb0c7e2 | 40788 |
sensor.ble_moisture_5c857eb0c7e2 | 40775 |
sensor.ble_temperature_5c857eb0c9a2 | 40732 |
sensor.ble_illuminance_5c857eb0c9a2 | 40718 |
sensor.ble_conductivity_5c857eb0c9a2 | 40710 |
sensor.ble_illuminance_5c857eb0c7e2 | 40705 |
sensor.ble_moisture_capteur_plante_dracaena | 40532 |
sensor.ble_illuminance_capteur_plante_dracaena | 40505 |
sensor.ble_temperature_capteur_plante_dracaena | 40450 |
sensor.ble_conductivity_5c857eb0c7e2 | 40387 |
sensor.ble_conductivity_capteur_plante_dracaena | 40314 |
switch.prise_tv_chambre_parentale | 39269 |
sensor.prise_tv_chambre_parentale_power | 39245 |
sensor.prise_tv_chambre_parentale_energy | 39245 |
sensor.sonoff_100178b0f6_power | 37555 |
sensor.daily_energy_peak | 33043 |
sensor.conso_journaliere_maison | 33020 |
sensor.monthly_energy_peak | 33005 |
sensor.weekly_energy_peak | 33000 |
sensor.yearly_energy_peak | 32995 |
sensor.0x00158d000966ca9b_base_cost | 32973 |
sensor.capteur_pied_elephant_temperature | 27011 |
sensor.capteur_dracanea_temperature | 22519 |
sensor.capteur_ficus_temperature | 22252 |
sensor.daily_gainable_energy_peak | 21372 |
sensor.sonoff_1000fcfd9e_energy_cost | 21347 |
sensor.weekly_gainable_energy_peak | 21346 |
sensor.yearly_gainable_energy_peak | 21343 |
sensor.sonoff_1000fcfd9e_energy | 21343 |
sensor.monthly_gainable_energy_peak | 21343 |
sensor.capteur_spathiphyllum_temperature | 20511 |
sensor.capteur_cactus_de_noel_temperature | 19283 |
sensor.capteur_caoutchouc_temperature | 18500 |
sensor.daily_energy_cost | 16261 |
sensor.monthly_energy_cost | 16235 |
sensor.yearly_energy_cost | 16230 |
sensor.weekly_energy_cost | 16228 |
sensor.daily_clim_gainable_energy_cost | 11039 |
sensor.weekly_clim_gainable_energy_cost | 11011 |
sensor.yearly_clim_gainable_energy_cost | 11007 |
sensor.monthly_clim_gainable_energy_cost | 11006 |
sensor.capteur_aspiration_clim_temperature | 10638 |
sensor.capteur_aspiration_clim_humidity | 10638 |
sensor.capteur_aspiration_clim_battery | 10638 |
Pensez vous que cela puisse « peser 3.5Go » ??
la commande mentionnée plus haut suffit elle a voir toutes les données sauvegardées dans la BDD ??
Merci
Salut
Aucun doute, le calcul de la taille est basé sur la vraie utilisation de l’espace disque.
Le seul point qui peut faire un peu varier ça, c’est le fait d’utiliser la l’option repack
qui taille le fichier au minimum. L’opération ayant lieu, tous les 30J (à cause du recorder) tu a peut-être un décalage.
Justement, à mon avis c’est absolument pas une bonne pratique. Taille de la base, temps de réponse, délai d’affichage/rafraichissement, tout ça c’est impacté
la config du recorder est prise en compte, à toi de voir (et d’adapter) si les sensor*_power sont utiles. Idem pour les sensor.*_over_voltage_breaker
recorder: je l’ai rajouté ce matin car à force je pensais que çamarchait pas , je vais le supprimer du coup ! merci
comme il est déclarer dans le configuration.yaml, pas besoin de le mettre dans le recorder.yaml:
recorder: !include recorder.yaml
Normalement, tu aurais une erreur si tu vérifie la config ou reboot.
ce que je pige pas c’est ca:
sensor.lixee_papp | 112092 |
---|---|
sensor.lixee_last_seen | 112092 |
sensor.lixee_iinst | 112092 |
sensor.lixee_current_tarif | 112092 |
sensor.lixee_base | 112092 |
sensor.lixee_adps | 112092 |
car dans mon recorder j’ai rentré :
entity_globs: # filtrage par entités similaires
- sensor.x50_*
- sensor.station_*
- sensor.time_*
- sensor.date_*
- sensor._last_seen
- sensor.threshold
- sensor.*power
- switch.disjoncteurbreaker
- number.disjoncteurthreshold
- sensor.lixee*
Je trouve étonnant de retrouver des traces des sensors lixee malgré ma déclaration … non ?
Faut laisser le temps passer, ça supprimera au fure et à mesure.
Chaque jours à 4h12 ta une purge auto et ça enlèvera une journée des sensors que ta exclu.
Perso, même avec un auto repack manuelle, ça m’a jamais tout supprimé d’un coup.
Faut pas oublier que ta des données à long terme, qui reste après le nombre de jours autorisé.
Tout ce qui a un state_class.
merci pour ton aide @WarC0zes , pourrais tu me partager ton recorder pour que je vois comment tu l’as organisé ?
Et le 04H12 il est modifiable où pas ?
Je te le partage quand je serais devant mon pc, par tablette ça va être compliquer.