Intro
J’ai récemment eu la désagréable surprise de constater une valeur anormalement élevée dans mon tableau « energy », en effet la conso totale jour HP était supérieure à 10000 kWh bien loin des valeurs habituelles.
Méthodologie apres 2022-04
Depuis la version 2022-04, HA offre la possibilité de modifier simplement les statistiques « longue durée ». Il faut vous rendre dans « outils de développement/statistiques ».
Vous cherchez votre entité corrompue avec la loupe
Vous cliquez sur l’icone de droite:
Vous sélectionnez la date, l’heure, vous cliquez sur la flèche correspondante à la valeur à rectifier:
Vous saisissez la nouvelle valeur et c’est terminé!
En cliquent sur « valeurs aberrantes », HA peut vous proposer une liste de valeurs aberrantes (ou pas) qu’il vous faudra analyser avant de les rectifier.
Merci HA, c’est quand même plus simple.
Modifications des données avant 2022-04
Méthode OBSOLETE
A ma connaissance, la seule méthode permettant de corriger les données est d’intervenir directement dans la base de données.
Prè requis pour ce tuto
- Utiliser mysql comme base de données (voir mon article sur le sujet)
- Avoir installer l’addon « phpMyadmin », c’est beaucoup plus simple et sécure de l’utiliser que de saisir les commandes avec le terminal!!
Avertissements
- Ce tuto applique à des utility-meter, il peut être différents pour d’autres type d’entités, mais j’ai pas testé. En effet le mode de calcul du « sum » est différent d’un type d’entité à l’autre.
- Faites une sauvegarde de votre base de données, des modifications avec une requête SQL peuvent être dévastatrices et il n’y a pas de possibilité de retour en arrière.
Mode opératoire
- 1- recherche de l’ID de l’entité concerné
- 2-modification de la table « statistics »
- 3-modification de la table « statistics_short_term »
Recherche de l’ID de l’entité concerné
Pour rappel, les entités éligibles aux « statistiques au long terme » sont stockées dans des tables spécifiques indépendamment des statistiques « temps réels » purgées par défaut tous les 10 jours.
Toutes les heures, les entités sont calculées et stockées dans une table « statistics ». Dans cette table chaque entité est identifiée par un « id » que vous allez récupérerez dans la table « statistics-meta »
Dans mon exemple, je cherche le « sensor.energy_total_usage_dayly_hp », vous sélectionnez la table « statistics-meta » , onglet « rechercher », saisir le nom de votre sensor dans le champ « statistic_id », vous pouvez utilisez le signe % comme générique.
Exécuter (en bas à gauche).
Si pas d’erreur de saisie vous retrouverez l’ID de votre sensor.
Dans mon cas, je note ID=28
Modification de la table « statistics »
Dans la table « statistics » vous « recherchez » les enregistrements relatifs à votre id.
Dans le champ « metada-id » vous saisissez l' »id » de votre sensor, 28 dans mon cas.
Vous délimitez le champ de recherche avec la date de création en sélectionnant dans le champ « created », « between », vous saisissez vos dates min/max, ajuster l’heure.
Exécuter (en bas à gauche).
Vous devriez voir apparaître votre « anomalie » dans les colonnes « state » et « sum » 10103 et 14451 dans mon cas, ce sont ces valeurs qu’il faut rectifier.
Pour modifier c’est pas compliqué, vous cliquez sur « Editer » de la ligne concernée.
Vous mettez à jour « state » et/ou « sum » avec vos valeur et vous « exécuter ».
Remarque: Pour « state », inspirez vous des valeurs des lignes environnantes pour vous donner une idée de la consommation à l’instant T.
Remarque: pour « sum » vous additionner votre « state » à la « sum » de la ligne précédente.
Vous constaterez que les « sum » postérieures à cette erreur sont toutes créditées d’un surplus de consommation. Vous pouvez les modifier à la main, ligne par ligne, en soustrayant le surplus à la « sum ». Cela peut être long et fastidieux si comme moi vous avez mis trop de temps à réagir.
Requete SQL:
L’autre solution est d’exécuter une requête SQL.
Attention à ce que vous faites, prenez bien soi de vérifier votre requête avant de l’exécuter, sauvegarder votre base de données.
Ce que nous voulons, dans la table « statistics », c’est soustraire une valeur, par exemple 10101, pour le sensor dont l’ID=28, aux valeurs de la colonne « sum » et partir d’un certaine date et si sum>10000, la requête SQL est dans ce cas:
UPDATE statistics SET sum = sum - '10006.0' WHERE metadata_id = '29' AND created >= '2022-06-18 00:00:00.0' AND SUM>'10000';Cette requête est à saisir dans l’onglet « SQL » après avoir sélectionner la table « statistics ».
Vous pouvez simuler la requête avant exécution, pratique pour s’assurer du résultat avant application définitive (pas de possibilité de retour en arrière!).
Si les résultats vous conviennent, vérifier notamment si le nombre de ligne concernée par la modification est cohérent, vous « exécuter ».
Visualiser le résultat de vos modifications dans le tableau « energy ».
Modification de la table « statistics_short_term »
Cette table est utiliser pour calculer les statistiques long terme, elle est purgée sur une période que vous avez défini dans votre configuration avec « purge_keep_days », le cas échéant c’est 10 jours par défaut.
Il faut donc également rectifier les « sum » et les « state » de cette table. Soit à la mano, soit avec une requête SQL du genre:
UPDATE statistics_short_term SET sum = sum - '10006.0' WHERE metadata_id = '28' AND created >= '2022-06-18 00:00:00.0' AND SUM>'10000';UPDATE statistics_short_term SET state = state - '10006.0' WHERE metadata_id = '28' AND created >= '2022-06-18 00:00:00.0' AND state>'10000';C’est exactement le même principe que la table « statistics »
Conclusion
Je ne vous cache pas que c’est un peu galère, notamment dans le calcul du « sum » qui est un cumul du « sum » précédent avec le « state « en cours, donc normalement le « sum » doit toujours croître, sinon vous retrouverez une conso négative.
PhpMyadmin est très puissant et permet de manipuler facilement les données, donc à utiliser avec prudence.
Si ce tuto n’est pas assez explicite, n’hésitez pas à me le faire remonter dans les commentaires.
Merci pour ce tuto, j’ai rencontré plusieurs fois cette erreur mas impossible de la corriger malgré avoir mis les mains dans le cambouis de phpMyAdmin, obligé de supprimer toutes les valeurs de linky et repartir avec un autre nom de sensor. La prochaine fois je testerai ton tuto 😉
Salut, comme depuis que j’utilise le relevé de conso j’ai eu un bug dans ma BDB, j’ai fait les manip que tu as expliqué mais lorsque le « statistics_short_term » se met à jour, toutes les 5 min, le state reprend la valeur erronée. Je t’avoue que ça fait trois fois que ça m’arrive, j’ai tout essayé mais impossible de revenir à des valeurs cohérentes, chaque fois j’ai été obligé de repartir à 0 dans mes conso linky. Si tu pouvais m’aider à résoudre ce problème, stp. Cordialement. Bob
Je n’ai pas réussi à corriger mon problème mais j’ai trouvé comment la valeur erronée apparaissait. le sensor « Linky HP KWH » créée dans le téléinfo renvoie une valeur à 0, de ce fait lorsque le calcul se fait et que la valeur est redevenu correcte, au changement suivant, il l’additionne, donc au lieu d’avoir +0.1 dans mon cas j’ai plus 7000 environ, qui correspond à la valeur de mon linky.
Bonjour, pour eviter les valeurs nulles j’ai ajouté un « filter out » dans les sensors HP, HC:
sensor:
# Energie Active soutirée totale
– platform: teleinfo
id: hc_hp
tag_name: « EAST »
name: « Linky HPHC KWH »
unit_of_measurement: « kWh »
icon: mdi:flash
teleinfo_id: myteleinfo
device_class: « energy »
state_class: « total_increasing »
filters:
– filter_out: 0.0
– lambda: |-
return x/1000;
# Energie Active soutirée Index01
– platform: teleinfo
id: hchc
tag_name: « EASF01 »
name: « Linky HC Wh »
unit_of_measurement: « Wh »
icon: mdi:flash
teleinfo_id: myteleinfo
filters:
– filter_out: 0.0
# Energie Active soutirée Index02
– platform: teleinfo
id: hchp
tag_name: « EASF02 »
name: « Linky HP Wh »
unit_of_measurement: « Wh »
icon: mdi:flash
teleinfo_id: myteleinfo
filters:
– filter_out: 0.0
Pour éviter ce genre de désagrément, après avoir lu une discussion sur un groupe facebook, avec l’aide d’un membre, j’ai créé un deuxième sensor avec un template, je l’ai testé et ça fonctionne très bien. Même si j’ai une valeur nulle, elle n’est pas enregistrée dans la BDB et ne fausse pas les calculs. Pour éviter de repartir à zéro j’ai renommé le sensor dans l’ESP32 linky_hp_kw en linky_hp_kw_1, puis j’ai crée un autre sensor avec ce template:
– platform: template
sensors:
linky_hp_kwh:
friendly_name: linky_hp_kwh
unit_of_measurement: kWh
device_class: « power »
value_template: « {% if states(‘sensor.linky_hp_kwh_1’)|float > 7300%}{{ states(‘sensor.linky_hp_kwh_1’)}}{% endif %} »
Bonjour, bonne idée, cela évite les valeurs aberrantes.
Maintenant on peut corriger directement en passant par Outils de développement, Statistiques, puis sur l’icône en bout de ligne , ajuster la somme.
Bonjour et merci pour l’info, j’ai loupé la update!!
J’ai mis l’article à jour, c’est beaucoup plus simple.
Slts