HA-Modification statistiques long terme

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.

Modifications des données

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 » 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';

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.

5 Comments on “HA-Modification statistiques long terme”

  1. 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 😉

  2. 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

  3. 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.

  4. 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 %} »

Répondre à Bob Annuler la réponse

Votre adresse e-mail ne sera pas publiée.

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.