bonjour, j’essaie de voir ma configuration RECORDER , et je suis pas doué … et j’ai peur de faire des bêtises …
J’aimerais garder mes données , temperatures et humiditée indefiniment avec un enregistrement toutes les 5 minutes et garder le reste comme c’est actuellement
d’aprés la doc, si j’ai bien compris , je met dans le config.yaml
mais que devient le reste ? c’est toujours conservé 10 jours ? ou il faud mettre
purge_keep_days: 10
pour un bleu , la doc est un peut hard et j’ai lus des cas où plus rien ne fonctionner , donc je voudrais pas faire de bêtises …
j’ai pas trouvé de tuto « simple »
J’espère que tu n’as pas sauvé ça car là oui : grosse bêtise en vue!
En fait le commit_interval, n’aura pas d’impact sur le nombre d’enregistrements, mais simplement sur le fréquence d’écriture dans la base de données. Comme expllqué dans la doc c’est utile pour les supports qui s’usent vite comme les cartes SD. Pas besoin de monter jusqu’à 350 sec.
Le commit interval c’est aussi potentiellement le max de données que tu peux perdre en cas d’arrêt brutal.
Ensuite. Si tu met uniquement le include du domaine « sensor » … tu perdra tout ce qui n’est pas une sensor!!!
Le purge_keep_days c’est pour toute la base, ça n’a rien à voir avec les include/exclude
La doc est plutôt logique je trouve, dans l’explications des include/exclude.
Il y a déjà eu des discussions ici pour régler tout ça. Avec des explications.
Les grosses questions pour commencer c’est: que cherches tu a faire? et sais-tu quels entités tu ne veux pas et qui te polluent la base.
Non … je te rassure . J ai deja apris à mes dépens a etre prudent …
Comme dis plus haut …
J’aimerais garder mes données de mes devices temperatures et humiditée indefiniment avec un enregistrement toutes les 5 minutes pour ne pas surcharge ma base de données, et garder le reste comme c’est actuellement …
Pour faire des comparaisons sur mes chauffages et insolations sur un long terme
Pour la doc … je comprend pas le principe des domaines , entity globs , events_type , etc …
…
Ce n’est pas avec le recorder que tu arrivera à ça. D’ailleurs tu n’en a même pas vraiment besoin
HA les garde indéfiniment si tu as les statistiques actives dessus, d’ailleurs depuis la 2023.12 ça affiche dans l’historique les données qui proviennent des statistiques. Donc là c’est plutôt une question de configuration des sensors avec les bonnes classes.
Sinon pour les notions de recorder:
domaines: ça englobe tout un type d’entités. genre - binary_sensor
entity globs : c’est une expression régulière genre - sensor.*battery
events_type : rien a voir avec les sensors.
Pour la doc … je comprend pas le principe des domaines , entity globs , events_type , etc …
J avais vue ca dans l explication de la nouvelle mise a jours … mais je n ai que 7 jours chez moi … c est pour ca que je me lancais la dedans .
Je regarde ca demain …
Salut,
pour le long terme, il faut que ton entity est un state_class en measurement , total ou total_increasing. Ce qui est normalement par défaut sur les entités température et humidité, rien a faire de ton coté au final.
Si ton entité ne dispose pas de state_class, tu peu l’ajouter en utilisant customize.
exemple (a mettre dans le configuration.yaml):
Merci pour toutes ces infos ,…
je viens de vérifier mes entity sont bien en state_class: measurement
si je vais dans l’historique effectivement je peux remonter assez loin …
par contre avec apexcharts , je n’ai que 10 jours max … même en mettant graph_span: 30d
c’est dû à apex ou il y a une astuce ?
sur Datetime – ApexCharts.js , ils donnent des exemples sur 5 ans !!!
Argh… Apexcharts effectivement je pense de base ne lit que le recorder… à voir si ça va être étendu aussi maintennat que l’historique de base le fait, peut-être que ce sera étendu.
Attention aussi pour ton exemple avec 5 ans. ApexCharts n’est qu’une librairie de visualisation de données. Elle peut être utilisée sur n’importe quel site web ou appli! C’est ce qui a été utilisé pour les cartes custo apexcharts, mais ce n’et que l’affichage. Ca n’a aucun lien avec la source de données.
