Bonjour Antonin,
J’ai supprimé le serveur de temps mais l’erreur de compteur ce produit toujours.
Toujours celui d’heure pleine bleu ainsi que celui d’heure creuse rouge.
Étonnant les compteurs HC et HP bleus sont tous deux sollicités en ce moment, pourtant un seul se désynchronise.
Pour le rouge c’est encore plus surprenant puisque celui ci n’est pas sollicité en cette période.
2 compteurs TIC sur 7 (6 tempo, 1 de production) se désynchronisent.
Cause différente ? Ou même cause mais dans d’autres circonstances ?
Vous avez un index production donc j’imagine que la tic est en mode standard ; HC rouge sur l’étiquette EASF05, HP blanc sur EASF04. Comme ces index ne varient pas en ce moment, quelles sont leurs valeurs correctes et quelles sont les valeurs d’erreur que vous avez obtenues pour HC rouge ? Cela permetrait de vérifier si la cause est identique en calculant la checksum.
Bonjour,
Oui je suis en mode Standard
Les deux (seuls) compteurs incriminés ont les valeurs suivantes:
Valeur TIC EASF02 14252718
Valeur compteur 18076439
Valeur TIC EASF05 488051
Valeur compteur 488099
Ci dessous la configuration et les valeurs de TIC
Concernant le checksum tu es partis de cette description ENEDIS ?
j’ai pas osé me lancer dans cette vérification de checksum.Je veux bien que tu vérifies
Je trouve vraiment louche que:
- seul 2 compteurs (pour l’instant tjrs les mêmes) présentent des erreurs.
- Que l’on ait pas plus de remonté de ce « bug » sur le forum.
Bonjour KAwDeS,
quelle est la marque et modèle du compteur ?
Bonne journée
Bonjour grocrabe,
C’est un ITRON ITE411L3B
Concernant la production PV ça semble être une bonne pioche.
https://forum-photovoltaique.fr/viewtopic.php?t=38996
Bonne journée également
Bonjour @KAwDeS,
Oui c’est bien cette description de ENEDIS.
Alors j’ai simulé le remplissage chiffre par chiffre du buffer TIC du edrt2 pour la transition entre EASF04 et EASF05, et le résultat le confirme, la cause est bien la même.
Le edrt2 considère EASF05 000488099 L alors que la valeur 488051 n’a pas finie d’être transmise. Il s’en suit une valeur 488099 erronée pour HC rouge.
Le linky n’est pas en cause dans ce cas.
Pareil pour l’autre, entre EASF01 et EASF02, le checksum arrive a être identique rapidement (+1 sur la différence entre 01 et 02 des étiquettes, et -1 sur la différence entre le chiffre 2 du premier index et 1 du 2ème index).
Bonjour @KAwDeS
Bonjour, je viens de vérifier, c’est OK pour moi. Je suis en Tempo avec PV également.
Mon problème se situe ailleurs : pas d’infos de prod sur le dashboard :
Je veux bien t’envoyer ma config si besoin…
Bonjour et merci pat49700, Antonin
Tu ne serais pas en mode historique 
Si tu peux faire une copie d’ecran des valeurs TIC et configuration compteurs.
Pour la production il te faut configurer le compteur
Config tarif
Config Cpt
Puis configurer le compteur sur ton Dashboard
Peux tu
essayer d’arrêter et de remettre en route tes compteurs blancs leurs valeurs ne semblent pas bonnes.
Me refaire une copie d’écran de tous tes champs du TIC.
1 « J'aime »
@antonin,
Comment cela peut être possible
Si la trame n’est pas bonne elle doit être rejetée me semble t’il.
Si une trame vient en écraser une autre pourquoi deux compteurs consécutifs ne sont pas HS.
@pat49700 , c’est autre chose que l’anomalie de comptage TIC, peut-être faudrait-il ouvrir un autre sujet plutôt ?
@KAwDeS , pour en revenir au sujet, concernant un éventuel contournement, je ne reproduis pas avec un serveur de temps inaccessible. Comment avez-vous rendu le serveur de temps inaccessible ? Pour ma part j’ai soit désactivé l’accès internet du edrt2 via ma box, soit mis une adresse de mon réseau local qui ne correspond à aucun objet connecté. Je suis en mode historique. Le mode standard serait-il plus sensible… Ce n’est pas une bonne nouvelle.
En tout cas il s’agit d’un défaut du edrt2 qui n’attend pas que le linky ait terminé sa phrase avant de la comprendre, pour employer un vocabulaire moins technique !
Citation
Comment cela peut être possible
Si la trame n’est pas bonne elle doit être rejetée me semble t’il.
Si une trame vient en écraser une autre pourquoi deux compteurs consécutifs ne sont pas HS.
La « trame » est bonne !!
C’est le edrt2 qui n’attend pas sa transmission complète.
Et comme le buffer contient la « trame » précédente, le checksum encore dans buffer peut correspondre à une valeur encore incomplète !!
Antonin,
Il est précisé dans la doc ENEDIS que la transmission est plus longue en standard, peut être que cela a une incidence.
On récupère beaucoup plus de champs, après je ne sais pas si l’edrt2 les reçoit tous ou seulement ceux configurés.
Je pense que c’est tous puis parsé suivant config.
C’est pour ça que j’ai demandé à @pat49700 sa configuration, j’ai ajouté au moins une étiquette pour avoir la couleur du lendemain peut être que ça pose pb. On va essayer d’avoir la même config pour voir si c’est reproductible.
Pour le serveur de temps j’ai supprimé l’adresse.
Peut-être que ce diagramme illustre mieux mon propos.
Le edrt2 ne devrait pas interpréter le bloc étiquette/valeur avant que celui-ci n’ait été complètement lu ! Cela n’a aucun sens.
Dans l’ordre, un bloc étiquette/valeur, un, doit être complet, deux, le checksum doit être valide.
Oui je comprend mieux
Pour le checksum il semble qu’il peut être horodaté.
Peut être suivant le mode.
Dans ce cas le checksum a bcp moins de chance d’être le même.
Par contre ça rallonge la transmission.
Citation
Pour le checksum il semble qu’il peut être horodaté.
Non, l’horodatage ne concerne que certaines données, pas ces données de relevé d’index.
Il y a un dernier coup à tenter pour le contournement : si vous mettez une adresse IP locale dans le champ serveur de temps ?
@antonin
C’est en test avec une IP locale.
J’ai aussi essayé de réduire le nombre de champs.
Bien bien. 
Linky transmet toutes les données successivement et en continu,toujours dans le même ordre tel que décrit dans le document d’Enedis. Le edrt2 les lit et peuple uniquement les champs qui ont été configurés. Réduire le nombre de champ ne devrait pas impacter la lecture.