Message d’un programmeur du dimanche
Nous avons tous l’obligation de configurer Le paramètre recorder pour limiter l’explosion de la base de données temporaire qui par défaut enregistre toutes les infos sur 10J (pas besoin de stocker le voltage de la pile ou la qualité du signal du capteur de température du garage toutes les secondes).
Dans un premier temps j’ai essayé de voir le type et nombre d’évènements enregistrés via une query et le module SQLite web.
A croire que ma conf de RECORDER ne fonctionne pas…
par exemple, j’ai indiqué que je ne voulais pas enregistrer sensor.neufbox* mais cela n’a pas eu d’effet
une idée de ce que j’ai mal complété ?
Salut,
le « presque » est important!
Si tu ajoutes une exclusion, les 10 jours de données ne seront pas supprimées tout de suite, ils le seront jour par jour.
Je ne connais pas les fréquence de mise à jour des valeurs de la neuf box…
Mais mettons qu’il reste 1 jours de données ,27000, correspond à 27000/24/60 = 18,75 msg / minute
Donc une valeur toute les 3 secondes, ce qui est possible pour de genre de donnée.
Mais si c’est toutes les 30 sec que tu as des valeurs e la box, effectivement tu as 10j de données…
C’est après les 10jours que tu peux en tirer des conclusions.
J’ai passé pas mal de temps sur le recorder et les exclusions que tu as mises marchent bien chez moi.
Je ne comprends pas la fonction Recorder. Je pense comprendre à l’envers le problème.
Dans le cas de @bobi92, il exclut de la purge de 10 jours les « sensor.esp32*signal » ? Donc il conservera les données indéfiniment ?
Par exemple, je souhaite garder les données stratégiques 520 jours et toutes les autres données de HA 10j.
Avec la fonction recorder, je souhaite converser pendant 520 jour une liste de capteur bien défini et conserver uniquement pendant 10j toutes les autres données de HA.
Actuellement, ma BDD fait 14Go ( ), normal je converse tout :
recorder:
purge_keep_days: 520
# Et rien d'autre !! Ne pas taper svp :D
Je me suis dit qu’un jour je devrais me pencher sur ce truc.
Est-ce que si je mets ça :
Que deviennent les autres données qui ne sont pas exclude ?
Est-ce qu’ils s’enregistre pendant la durée par défaut de HA (10j) ? Ou bien ils ne seront pas enregistrés
?
Dans le même thème > il y a une méthode pour activer la purge à la demande sans attendre 4h du matin ? C’est pour des tests ensuite.
Donc les données du 1er groupe « include » seront conservées pendant 548 jours
Et pour le groupe « exclude », il n’y aura rien, aucune trace même pas un log ?
recorder:
purge_keep_days: 548
auto_purge: true
include:
domains:
- person
- sensor
- sun
- zone
- binary_sensor
- cover
- button
- calendar
- device_tracker
- switch
- climate
- number
- alarm_control_panel
- camera
exclude:
domains:
- media_player
- update
- automation
- weather
- remote
Ouai soit on garde des choses pendant xx jours, soit ça file à la poubelle automatiquement.
Pas trop le choix de dire ça je veux garder 1 an, ça 6 mois, et ça 1 mois, avec ça 2 semaines, puis le reste 1 jour…etc.
C’est très limité et on à connu mieux en terme d’optimisation.
Pour autant je suis pas convaincu que la mécanique ‹ à la jeedom › soit bien meilleure et de vouloir l’appliquer à HA soit sain …
Personnellement j’ai toujours pas compris le besoin. Par exemple tu fais quoi de l’historique de tes interrupteurs (switch) sur les 2 dernières années ?
Aucune importance, je peux le mettre du côté exclude en le retirant de include.
Idem avec le domaine number.
Et là je commence à optimiser maintenant que la logique et les limites sont comprises.
Par contre le service-purge ne semble pas avoir d’effet sur ma personne. On doit répéter les paramètres du recorder dans le service ou bien il vient chercher les infos tous seul ? Sinon j’attends demain matin.
Tout à 10j, et ce qui ne sert strictement à rien (time, date update et la liste est longue), dans les exclude direct sans réfléchir
Les quelques données à conserver (on parle des vraies données essentielles : des consos, des températures) sont à mettre dans les stats pour une durée de stockage infinie et on s’assure que pour ces données, on garde les éléments significatifs (genre les températures: 1/heure c’est large, la conso électrique : 1 somme/jour etc)
Si c’est cette direction vers laquelle tu tends, alors il n’y a pas de problème, tu sera tranquille.
Sinon, et notamment en partant du principe de tout mettre ‹ au cas où ›, tu auras forcement un jour ou l’autre un souci de taille, avec l’espace disque ou la restauration.
Quant à la purge, elle fonctionne sans aucun doute, reste à savoir quelle effet tu attends… Un repack par exemple aide à réduire la taille effective du fichier de la BDD
Yes cela semble fonctionner.
Je viens de maigrir de +/-200Mo avec quelques trucs peu utiles.
Je vais continuer exercice.
HS > J’ai lu sur le forum comme quoi utiliser MariaDB serait moins gourmand en place. Vrai ou faux ?
Pour accéder aux détails de la bdd (savoir qui est le plus gourmand) avec phpmyadmin il faut obligatoirement MariaDB ou bien il y a des outils sympas de disponible de base ?
commande pour voir les 20 entitées les plus grourmande:
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;
), normal je converse tout :