Bonjour,
Je confirme également le bon fonctionnement de la lib teleinfo suite à ton check sur les caractères autorisés lors du calcul du checksum.
J'avais une ou deux alertes par jour mais plus rien depuis. J'ai un abonnement Base en mode Standard.
Merci pour ton travail, aussi bien sur la carte que sur le soft.
Bonne journée
Ma liaison Linky/Denky est effectivement bien moins perturbée, mais mon watchdog s'est quand même déclenché deux fois aujourd'hui. Depuis, tous les compteurs de stats restent à zéro.
Je vais laisser tourner quelques jours pour avoir plus de statistiques et après je bascule sur un firmware avec ton dernier patch.
Bonne soirée.
@Charles Le code source que j'ai relu incluait ta dernière Pull Request qui n'est pas encore dans le build officiel ... Donc oui, cette nouvelle vérification lors du calcul du checksum devrait être très efficace !
D'après les stats du Denky, j'ai environ 10 "Bad Checksum" par jour. Je ne suis donc pas un bon candidat pour tester une acquisition bruitée ...
J'ai mis en place un Watchdog sur Jeedom qui surveille la collecte de données Teleinfo. Sans nouvelle remontée d'information au bout de 5 minutes, j'envoie une commande MQTT de reset au module. Pour ceux que ça intéresse, J'ai incrémenté une variable à chaque reception de données valides. Cette dernière est vérifiée toutes les 5 minutes par un scénario. Si la variable est différente de zéro, des données arrivent et on remet le compteur à zéro. Dans le cas contraire, on reset le Tasmota et on post un e-mail d'alerte.
Bonne journée
J'ai regardé le code source de LibTeleinfo.cpp et j'arrive à la même conclusion que toi. Lors du calcul du Checksum, au moindre caractère qui sort des clous, la fonction retourne 0, qui n'est pas un checksum valide. Pour intégrer un couple tag + valeur, il faut que le Checksum extrait de la trame soit différent de zéro et égal au Checksum calculé.
Du coup, la corruption que l'on observe peut difficilement être expliquée par une corruption de la trame entrante car elle devrait être détectée dès le calcul du checksum et exclue, même si le checksum extrait est valide (une chance sur 64).
Une routine périodique qui parcourt la liste de tags et exclu les "chelous" me semble une solution de contournement efficace. Même si c'est plus satisfaisant d'identifier la corruption à la source.
J'ai activé les stats et j'ai pour l'instant un seul 1 seul "Bad Checksum"
Bonne soirée.
Bonjour Charles et bonjour Messieurs,
Je vais suivre avec attention ce fils de discussion car j'ai constaté le même problème chez moi.
Mon Denky D4 est en batterie depuis seulement quelques jours (sur un Linky en mode Standard), et j'ai déjà été obligé de le redémarrer 2 fois. La cause est toujours la même, un des tags du TIC contient un caractère étrange et la payload MQTT n'est plus considérée comme du JSON valide. Ce TAG est toujours un duplicata d'un TAG valide ce qui me fait également penser qu'il a été corrompu (avant ou après Cheksum) puis ajouté à la liste des TAGs.
Du coup, même si je reçois toujours un flot d'information MQTT sur mon Jeedom, les données ne sont plus dispatchées. J'envisage un scenario Jeedom qui redémarre le Denky si aucune données n'est dispatchée pendant plus d'une minute, mais régler le problème à la source est pas mal non plus 
Je vais donc d'abord vérifier la qualité de réception des informations sur le Denky D4 (volume de checksum NOK) puis tester les firmwares alternatifs proposés.
Bonne journée.
Bonjour @Charles,
Tout d'abord, un grand merci pour ton travail. J'utilise un module micro téléinfo V2.0 depuis plus d'an maintenant, et il marche du tonnerre ! J'ai juste eu besoin d'une modif hardware pour lui faire accepter le passage du Linky en mode Standard.
Je viens juste d'acheter un Denky D4 pour pouvoir sortir mon raspberry du garage (à coté du Linky, obviously) et le mettre à l'abris derrière un onduleur dans la maison.
Ma config:
Rasberry Pi 4 avec Jeedom et le plugin JMQTT, entres autres. Le Broker est également sur le Rasp.
J'ai des modules domotiques en Wifi (Shelly) et en Zigbee (SonOff, Xiaomi et même Lidl !)
Le Linky:
Un seul compteur, en mode Standard car production photovoltaïque pour autoconsommation avec revente de surplus, presque comme Nicolas.
Mes constations.
La simplicité de configuration de Tasmota est enthousiasmante, j'ai très vite eu des trames MQTT remontées jusqu'au Broker et visibles dans Jeedom. Mais lors de mon premier vrai test, avec des informations de TIC, j'ai eu également un blocage:
Les premières payloads MQTT TIC étaient bonnes, dans le sens JSON du terme: Jeedom me permettait de les éclater en sous modules pour faciliter la création de nouvelle commandes. Et puis brusquement, les informations ne remontaient plus. La payload TIC était toujours reçue régulièrement mais contenait systématiquement un éléments étrange en bout de chaîne: "EST":8062115. Jeedom ne considérait plus cette payload comme du JSON valide. Il me semble qu'il s'agissait d'un doublon de l'info EAST mais avec un caractère corrompu. La valeur correspondait bien à l'info EAST, mais un peu plus ancienne et non mise à jour.
Le test d'aujourd'hui a été beaucoup plus stable (plus d'une heure), j'ai branché plus sérieusement les fils à la carte Denky D4. Chance ou effet réel ? je ne bascule pas tout de suite sur cette solution car j'attends une potentielle compatibilité MQTT du plugin teleinfo de Jeedom.
Je peux fournir des exemples de payload avec le défaut et des exemples fonctionnels. Et accessoirement, J’habite également dans la Vienne, à coté de Châtellerault
Bonne soirée