Brusque anomalie de comptage aujourd’hui entre 13h et 14h.
Alors que le tarif en cours est HPJW, j’ai un comptage en HCJW de plus de 15 kwh qui s’ajoute au comptage en cours en HPJW !
La mesure par le tore est, elle, correcte et correspond à la réalité du comptage HPJW.
Bien sur, ça perturbe tous les compteurs basés sur la télé-info… Et possiblement à l’avenir quand il y aura une nouvelle période de HCJW.
Je n’ai changé aucune configuration, uniquement fait de la consultation des postes et des graphiques.
… bon, j’ai creusé un peu, je complète. Le problème vient d’une possible perturbation de la lecture de la téléinfo. L’index courant HCJW est incorrect sur l’ecodevice comparé à celui que j’ai lu sur le compteur.
Du coup, pour arranger tout ça au mieux, je reconfigure cet index ? Je reconfigure aussi le sous-poste que j’ai associé à cet index ?
Merci !
Super, j’ai corrigé l’anomalie de téléinfo !
J’ai eu un peu de boulot…
Le principe :
1- sauvegarde globale de la configuration et de l’historique
2- mise à jour de l’index TIC/prix en faute et de l’historique du jour et jours suivants (horaire, quotidien) dans le fichier system.gce
3- restauration
Et pour que l’opération soit la plus rapide possible pour ne pas perdre trop de Wh, j’ai développé un bout de code qui a fait la sauvegarde et la mise à jour du fichier.
J’ai fait la restauration manuellement avec l’interface graphique (l’opération en elle-même y compris le reboot a pris 1mn 30).
Sans correction du compteur (qui avait une valeur supérieure à la réalité), la conso/prix horaire/quotidienne reste à 0. C’est une forme de résilience… c’est comme si la conso/prix était « constatée d’avance ». Je suppose que le compteur aurait continuer à compter dès lors que la valeur réelle serait redevenue supérieure.
Depuis ce 13 avril, j’ai déjà eu 3 fois une erreur sur l’index HCJW (HC jour blanc du tarif tempo), le 13, le 21 et aujourd’hui le 25.
Ce qui m’étonne, c’est que l’erreur survient toujours sur ce même index HCJW.
Encore une erreur ce jour sur l’index HCJW, avec un comptage de 30 kWh (alors que l’index n’aurait pas dû bouger, la période étant en heure pleine) ! 4 erreurs en 2 semaines et ça fait à peine un mois que j’ai installé le EDRT2.
Du coup j’avais mis en place une scène pour savoir si c’était directement l’étiquette BBRHCJW de la TIC qui variait au lieu de conserver la valeur courante, et c’est bien elle.
Je ne pense pas qu’il s’agisse d’une perturbation dans la transmission : c’est toujours BBRHCJW qui a un problème ; si il y avait des perturbations, ce serait sur n’importe quelle donnée il me semble.
Soit c’est linky qui remonte une mauvaise information (mais considérée comme bonne si le checksum est correct), soit c’est le EDRT2 qui inscrit une mauvaise valeur dans le champ.
Dans mon investigation (déformation professionnelle d’informaticien) du fichier de sauvegarde de config system.gce, j’ai repéré un journal d’évènements. Certains contiennent un horodatage, et à chaque intervalle horaire où il y a eu le problème correspond exactement un évènement. Ce qui m’interpelle est la certaine récurrence de l’heure :
Comme si il y avait un lien avec les arrêtés d’index toutes les 1/2 heures de mon linky…
Je pense qu’il ne me reste plus maintenant qu’à contacter directement le service support de GCE.
Ce qui est très embêtant pour l’intérêt des graphes, des fonctions de comparaison, etc, c’est qu’il n’y a pas d’auto-correction (l’étiquette TIC redevient correcte, peut-être à la transmission suivante ; au cas où le problème viendrait bien de linky).
J’ai identifié une partie de ce qui se passe. La valeur de l’erreur n’est pas aléatoire ! Elle est exactement toujours le résultat d’un même calcul.
C’est très surprenant, mais la valeur de l’index TIC Heure Creuse Jour Blanc est temporairement substituée par la valeur de l’index Heure Pleine Jour Bleu !!!
Les deux index n’ayant évidemment rien à voir, la différence de leur valeur donne une consommation totalement erronée.
Reste à savoir si c’est Linky qui substitue par erreur la valeur de BBRHCJW à celle de BBRHPJB ou si c’est l’EDRT2. Le problème est que cette substitution a lieu ponctuellement et n’est pas systématiquement reproduite. Néanmoins, quand elle a lieu, elle semble calée sur des multiples de 10 mn. Statistiquement, les horaires les plus fréquents sont : heure, ou heure + 10 mn, ou heure et demi + 10 mn.
Quand bien même la valeur de BBRHCJW redevient correcte, le compteur de l’EDRT2 ne revient pas en arrière, ce qui fait que l’erreur n’est pas auto-corrigée par une soustraction et cela rend les données TIC inexploitables.
sans vouloir systématiquement défendre les produits GCE, le fait que vous soyez le seul à rencontrer le pb plus le timing des erreurs fait vraiment penser à un pb du Linky et pourrait être lié au moment ou il stocke les index (lesquels seront transmis entre minuit et 6 h).
J’ai le même sentiment.
Peut-être que cette erreur là exactement, je suis le seul à l’avoir, mais le fait que Linky puisse retourner de temps en temps des valeurs d’index erronées, je me dis que ça existe surement ailleurs et que ce genre d’erreur est prévisible.
Je n’ai actuellement pas les moyens de vérifier si c’est une mauvaise donnée dans une trame correcte. J’imagine que les trames incorrectes ou incomplètes sont déjà ignorées (ce serait un premier point à savoir). Ayant acheté l’écodevice, je n’ai pas aussi acheté un modem TIC.
Après le développement et la mise en place d’utilitaires logiciels ainsi qu’une période d’observation (et pas mal d’énergie et de temps dépensés…), je peux mettre en évidence le problème, et il proviendrait bien du EDRT2 !
Il concerne tous les index, et potentiellement toutes les valeurs d’une étiquette TIC (je reprécise que je suis en mode historique et n’ai observé que ce mode).
Il est dû à une récupération anticipée de la valeur, avant que le groupe complet étiquette+valeur+checksum n’ait été transmis et stocké. Le stockage conservant les transmissions des groupes précédents, dans certaines circonstances et en particulier lorsque la valeur du checksum est identique pour 2 valeurs différentes, cela génère une prise en compte erronée.
Exemple
Les 3 groupes suivants sont corrects (format correct, checksum correct) et les 3 sont pris en compte par le EDRT2 :
BBRHPJB 009518319 N
BBRHCJW 000348319 N
BBRHCJW 000342427 H
Pourtant, le 2ème groupe n’aurait pas dû être pris en compte : il correspond à un état transitoire du buffer qui contient une partie du groupe en train d’être transmis BBRHCJW 00034 et le reliquat du groupe précédent 8319 N. La valeur valide transmise est 000342427.
Suivant si la valeur lue et considérée comme correcte est supérieure ou inférieure à la valeur en cours, la conséquence diffère :
si la valeur est supérieure, elle est prise en compte (cas visibles à l’origine de ce sujet et dans l’exemple)
si la valeur est inférieure, elle est ignorée
J’espère désormais un correctif si le problème concerne tous les EDRT2.
J’ai donné une solution de contournement dans le sujet général tempo, mais ce sujet étant très dense en échanges je poste aussi ici des informations.
D’autre part cela ne concerne pas que le tarif Tempo : Tempo est peut être plus touché tout simplement parce qu’il y a 6 index TIC.
Vu de l’extérieur, il y a 2 facteurs qui engendrent le problème :
le buffer qui contient la TIC n’est pas remis à 0 après la lecture d’une étiquette/valeur : cela engendre les problèmes de « collision » décrits plus haut
la lecture du buffer est visiblement perturbé par la synchronisation de l’horloge toutes les 10 minutes : cela engendre un potentiel problème de lecture de la TIC toutes les 10 minutes !
Concernant l’horloge, il y a un bug (logiciel, pas matériel) qui fait que l’horloge ne passe jamais par 59 secondes (par exemple passage de 8:23:58 à 8:24:00 sans passer par 8:23:59).
Il s’ensuit un décalage de 1 seconde par minute, soit 10 secondes toutes les 10 minutes. Si l’horloge est synchronisée avec un serveur de temps (paramétrage de l’Ecodevice), alors les 10 secondes sont rattrapées lors de la synchronisation toutes les 10 minutes. La synchronisation corrige donc artificiellement le bug de l’horloge.
Pour limiter le problème de la lecture de la TIC, l’idée est de désactiver la synchronisation de l’horloge dans le paramétrage de l’Ecodevice et de définir la valeur de l’horloge manuellement.
La conséquence est la dérive de 1 seconde par minute… mais j’ai remarqué que l’horloge s’auto-corrigeait toutes les 4 ou 6 heures (valeur à confirmer), ce qui fait que au maximum il y a un décalage de 4 ou 6 mn seulement. Je pense que cet effet est lié au bug du non passage par 59 seconde (j’ai l’intuition d’un mélange de valeurs entre les secondes et les minutes au moment du calcul à partir d’un temps exprimé en valeur EPOCH, mais bon je ne suis pas dans le code…).
En limitant très fortement le nombre de synchronisations, cela limite les problèmes des index TIC. J’utilise cette solution depuis octobre 2023 et je n’ai plus eu aucun problème depuis (soit depuis plus de 3 mois).
De temps en temps il faut vérifier que l’horloge est à l’heure et éventuellement mettre à jour manuellement. L’horloge « matérielle » parait stable.
@grocrabe Y-a-t-il une possibilité de changer le titre de sujet qui est plus général (genre : « Anomalies valeurs TIC » ?) ?
Je m’étais amusé à trouver le nombre de possibilités d’avoir des checksums identiques avec des valeurs en partie communes, à partir de mes index de départ et en faisant varier un des index.
Exemple:
BBRHPJB 009617433, BBRHCJW 000342427 qui va rester fixe pendant que BBRHPJB va varier de 50000 Wh sur un mois par exemple (typique en belle saison où il n’y a pas de jours au tarif blanc).
J’ai trouvé 1812 possibilités sur 50000 cas, ce qui fait une certaine probabilité pour que ça tombe au moment de la resynchronisation d’horloge.
En tarif HC/HP, les deux index varient tous les jours et dans une proportion moindre. Je pense que le nombre de possibilités est beaucoup plus faible.
Dans tous les cas, si ce ne sont que les derniers digits qui sont concernés (on est en Wh), ça peut passer inaperçu.
Exemple de valeurs d’index HC/HP où il y a un checksum identique :
Si la 3.00.05b2 corrige bien l’horloge (et c’est un très bon point !), le problème de TIC décrit dans ce sujet reste lui bien présent, en particulier lorsque le edrt2 est connecté au serveur de temps.
Je m’en suis rendu compte quelques jours après avoir remis la connexion au serveur de temps, alors que le problème n’est jamais survenu si le edrt2 n’a pas accès au serveur.
Seule solution désormais : corriger cette implémentation de lecture qui interprète une donnée pas encore complète et mélangée avec la donnée précédente.
Désolé de commencer la semaine ainsi ! Bonne journée.
Bonjour,
Je suis également en 3.00.05b2 et je rencontre également un pb de compteur TIC.
J’ai un abonnement TEMPO et je suis producteur soit 7 compteurs de configurés.
J’ai refais plusieurs fois la configuration de compteurs notamment l’HP bleu.
Ca ne tient pas une journée.
La partie graphique est inexploitable avec une superposition des HC et HP.
Vivement un correctif Pour autant les index que j’enregistre sur mon NAS depuis un script n’ont pas d’erreur, ce qui m’interroge
Si le script utilise les API qui récupèrent directement les index TIC (valeurs du Linky) et pas les valeurs courantes des compteurs du edrt2, alors c’est normal que les captures soient correctes (la probabilité qu’elles soient incorrects est faible et dépend de la fréquence des captures par script).
Les compteurs du edrt2 sont eux mis à jour presque à chaque remontée de la TIC compteur (en mode historique au moins, mais je ne sais pas en standard). La probabilité d’avoir l’erreur est plus grande.
En ce qui me concerne je n’ai pas d’erreur si l’horloge n’est pas synchronisée (j’ai mis une adresse IP locale bidon pour le serveur de temps ; l’autre solution est d’interdire l’accès internet au edrt2 via la box).
Précision : une fois qu’un compteur edrt2 a été mis à jour avec une valeur erronée, la fois suivante qu’une valeur est transmise, si cette valeur est inférieure à la valeur courante erronée du compteur, alors le compteur n’est pas mis à jour (il ne revient jamais en arrière). Mais l’API Get TI, elle, récupère cette dernière valeur.
Vous êtes sûr de récupérer les bonnes valeurs par script si le script ne s’exécute pas sur les multiples de 10mn de l’heure du edrt2 (si l’horloge est synchronisée), puisque c’est à ces moments seulement qu’il y a les soucis d’erreur.
