Je souhaite modifier cette valeur 0.28 du 31 Mars à 23:00:00 :
par cette valeur (135.62):
Pour cela, je pense utiliser l’outil ‹ Ajuster une statistique ›. Je ne comprends par pourquoi à l’endroit du 31 mars 2024 à 23:00 figure la valeur -135.6 à la place de 0.28 ?
Enfin, je pense que la valeur est calculée en fonction de la valeur précédente. Mais j’aimerais avoir votre avis!
Bonjour,
Je n’ai jamais vu les valeurs changer toutes seules. Comment est définie la valeur? Quel est le type d’entité de ton sensor.cout_total_par_mois_hc_hp?
Tu dois en effet pouvoir corriger avec l’outil « Ajuster une statistique », mais ilfaudrait comprendre comment la valeur erronnée a pu être créée pour éviter que ça se reproduise.
Voici la définition de cout_total_mois_hc_hp.
sensor.consommation_totale_mois_hp et sensor.consommation_totale_mois_hc sont générés par un compteur de service.
Mon problème est que la dernière valeur du mois de mars est défectueuse. Pour moi, elle aurait du être générée au premier avril. la conséquence est que plotly-graph prend cette valeur erronée pour fabriquer la conso de mars!
- unique_id: cout_total_mois_hc_hp
name: Coût total par mois HC-HP
state: >-
{% set hp = states('sensor.consommation_totale_mois_hp') | float(default=0) | round(2) %}
{% set hc = states('sensor.consommation_totale_mois_hc') | float(default=0) | round(2) %}
{% set cout_hp = states('input_text.tarif_heure_pleine') | float %}
{% set cout_hc = states('input_text.tarif_heure_creuse') | float %}
{{((hp*cout_hp) + (hc*cout_hc)) | round(2)}}
unit_of_measurement: "€"
device_class: monetary
state_class: total
Il y a donc forcément l’un des deux sensor de consommation qui est passé en négatif pour que le résultat soit négatif. Tu as regardé l’historique de ces 2 sensors au changement de mois?
En fait mon problème n’est pas l’origine de cette valeur mais de comprendre pourquoi je ne vois pas la même valeur dans la fenêtre ‹ Ajuster la statistique › que celle visible sur la courbe.
0.28 sur la courbe
-135.6 dans la fenêtre ‹ Ajuster la statistique ›
La table statistique pour des sensor avec state_class = total_increasing stocke 2 valeurs : la valeur du compteur d’origine (index) et la différence avec la valeur précédente (la conso), qui est calculée par HA.
Le comportement de la table statistics est identique à celui d’un utility_meter, qui transforme une valeur d’index en une consommation.
Normalement, la courbe affiche le compteur, mais dans l’outils de correction tu vois la différence. C’est celle ci qu’il faut corriger. HA va alors recalculer les conso.
Si tu connais le SQL et veux mieux comprendre, tu peux toujours faire avec SQLLite web une requête pour regarder le contenu de la table Statistics. Le modèle de données est décrit ici :
Tous les champs ne sont pas utilisés car cela dépend de state_class….
Normalement, la courbe affiche le compteur, mais dans l’outils de correction tu vois la différence. C’est celle ci qu’il faut corriger. HA va alors recalculer les conso.
J’ai corrigé dans l’outil de correction mais la modification n’apparait pas sur la courbe même après le redémarrage de HA!
Tu es sûr d’afficher les statistics et pas les états ?
Tu as 3 historiques qui se complètent :
En cas de doutes et si tu connais SQL, tu peux toujours regarder le contenu des tables, pour identifier le pb.
Mon avis : Home Assistant a plein de qualités mais est vraiment très mal fait pour la gestion des historiques.
Historique et statistiques sont trop séparés et on a au final 2 types d’historiques gérés à des endroits différents.
On obtient vite des incohérences, en particulier sur les classes d’état de type total_increasing. Typiquement, si un sensor calculé prend ses valeurs d’autres sensors, qu’un seul des sensor source passe à 0 (reboot HA par ex), alors le sensor calculé deviendra faux. L’outil de correction est juste un plâtre sur une jambe de bois car le pb devrait être gérable à la source…
HA n’a même pas d’outils de purge des historiques, d’option par entité pour indiquer si on veut ou non stocker l’historique, quels sont les paramètres de stockage (durée et période), comment sont précalculées les statistiques (sum, mean, min, max…)
Il faut être très averti sur les paramètres à spécifier (bon device_class par ex) pour que des statistiques sont bien créées.
Sans parler des courbes par défaut de HA qui n’ont pas de sélecteur de période dans le dashboard, dissocient les historiques cours et longs termes, ne savent même pas gérer les total_increasing comme le fait la courbe du tableau énergie.
Bref, j’arrête la 
J’espère que cela t’éclaire quand même sur le sujet et ne te décourage pas.
Tu as raison, selon ce qu’on regarde on ne voit pas la même chose!
En ajustant une statistique, on ne modifie apparemment pas les states mais peut-être les Statistiques à long terme. Si c’est le cas je devrais voir ma modification dans quelques heures vu qu’elle porte sur le 31 mars 23:00:00.
Salut Philippe,
Selon ma compréhension, les statistiques court terme (période de 5mn) sont stockées pendant 10 jours, en même tant que les états (state). Puis après 10 jours (ou 5 d’après ce qui tu observes ??), les statistiques court terme anciennes sont transformées en statistiques long terme (période 1 heure) et purgées. Les statistiques long terme ne sont jamais purgées par contre.
La correction ne modifie effectivement pas les états, mais uniquement les statistiques (court ou long terme).
Pour voir les statistiques, tu peux utiliser un statistic graph (différent du history-graph qui lui affiche les états).
Tu peux aussi utiliser une history explorer card, qui a le mérite d’avoir un sélecteur de période et pas mal de possibilités.
Peux-tu vérifier avec un de ces graphiques si ta correction a porté ses fruits ?
@+
La période modifiée est à présent dans les statistiques à long terme mais les valeurs ne sont toujours pas modifiées! Les valeurs ajustées sont toujours présentes dans la fenêtre ‹ Ajuster la statistique ›.
Conclusion: Modifier les states ou les statistiques à long terme par cette méthode est inefficace!
J’ai valeurs affichées avec statistics-graph et history-explorer donnent la même chose. Les modifications ne sont pas prises en compte!
Est-il possible de modifier facilement les statistiques à long terme avec SQLite Web?
Il est tout à fait possible de modifier les statistiques à long terme avec l’add-on SQLite Web.
Je montre ici comment j’ai procédé pour modifier une valeur. Je pense que cela pourra être utile à d’autres.
D’abord, j’ai récupéré l’id de mon sensor avec la requête suivante:
SELECT *
FROM "statistics_meta"
WHERE statistic_id = "sensor.cout_total_par_mois_hc_hp"
Le résultat est id=251.
Ensuite j’ai recherché la valeur à modifier avec la requête suivante entre le 31 mars 21:00 et le 1 avril 03:00. J’ai utilisé un transcodeur date-to-timestamp pour cerner la bonne valeur. Mon but est modifier la valeur du 31 mars 23:00 en 135.90.
SELECT * FROM "statistics"
WHERE metadata_id = 251 and created_ts >= 1711911600 and created_ts <= 1711939600
order by created_ts
La valeur à modifier a l’id 1036028.
J’ai utilisé la requête suivante pour la vérifier:
SELECT * FROM "statistics"
WHERE id = 1036028
Enfin, j’ai modifié la valeur avec ceci :
UPDATE "statistics"
SET state = 135.90
WHERE id = 1036028
Et le tour est joué!