Bonjour,
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.
Historique du jour avec l’anomalie
Historique du jour tel qu’il aurait du être
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.
Bonjour antonin,
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).
Bonne journée
Bonjour grocrabe,
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.
Bonne soirée.
1 « J'aime »
