Trames corrompues MQTT
-
@Charles complément ...
c'est bien une ESP32 et j'ai tenté la mise a jour par la web UI ... (c'est mieux quand on lis les questions jusqu'au bout !)
Finalement j'ai flashé "en dur" et ça a fonctionné mais j'ai toujours des erreurs de checksum ...
Y'a t'il un lien avec le fait que les trames MQTT ne sont pas formatées en JSON ?
je m'explique la première trame reçue par le broker est bien en JSON mais pas les suivantes ...Merci
-
Vu que je suis en Tempo triphasé, mon compteur cause beaucoup mais avec un bon format json
16:20:51.039 MQT: tele/Linky/SENSOR = {"TIC":{"ADSC":"022276116693","VTIC":2,"NGTF":"TEMPO","LTARF":"HP ROUGE","EAST":1291834,"EASF01":918154,"EASF02":108799,"EASF03":121563,"EASF04":122694,"EASF05":8101,"EASF06":12523,"EASF07":0,"EASF08":0,"EASF09":0,"EASF10":0,"EASD01":1047818,"EASD02":244016,"EASD03":0,"EASD04":0,"IRMS1":1,"IRMS2":1,"IRMS3":1,"URMS1":241,"URMS2":241,"URMS3":241,"PREF":12,"PCOUP":12,"SINSTS":518,"SINSTS1":228,"SINSTS2":125,"SINSTS3":162,"SMAXSN":7010,"SMAXSN1":2560,"SMAXSN2":2080,"SMAXSN3":2360,"SMAXSN-1":7010,"SMAXSN1-1":2830,"SMAXSN2-1":2100,"SMAXSN3-1":2330,"CCASN":390,"CCASN-1":504,"UMOY1":240,"UMOY2":241,"UMOY3":239,"STGE":"833A5401","DPM2":0,"FPM2":0,"PRM":2147483647,"RELAIS":0,"NTARF":6,"NJOURF":0,"NJOURF+1":0}}J'ai encore des trames bizarres sur la fin mais il semble que cela reste un json correct voir le tag 30300113310000 en fin de trame après quelques temps
16:12:47.687 MQT: tele/Linky/SENSOR = {"TIC":{"ADSC":"022276116693","VTIC":2,"NGTF":"TEMPO","LTARF":"HP ROUGE","EAST":1291776,"EASF01":918154,"EASF02":108799,"EASF03":121563,"EASF04":122694,"EASF05":8101,"EASF06":12465,"EASF07":0,"EASF08":0,"EASF09":0,"EASF10":0,"EASD01":1047818,"EASD02":243958,"EASD03":0,"EASD04":0,"IRMS1":1,"IRMS2":1,"IRMS3":1,"URMS1":240,"URMS2":242,"URMS3":240,"PREF":12,"PCOUP":12,"SINSTS":504,"SINSTS1":205,"SINSTS2":137,"SINSTS3":161,"SMAXSN":7010,"SMAXSN1":2560,"SMAXSN2":2080,"SMAXSN3":2360,"SMAXSN-1":7010,"SMAXSN1-1":2830,"SMAXSN2-1":2100,"SMAXSN3-1":2330,"CCASN":390,"CCASN-1":504,"UMOY1":239,"UMOY2":240,"UMOY3":239,"STGE":"833A5401","DPM2":0,"FPM2":0,"PRM":2147483647,"RELAIS":0,"NTARF":6,"NJOURF":0,"NJOURF+1":0,"30301131000":237}}Je continue de surveiller cela, mais pour le moment je récupère des trames cohérentes.
MErci
-
@labu73 Aucune amélioration de mon coté ... il me semble que @Charles a évoqué un probleme sur les trames standard ...
Capture d’écran 2023-03-01 à 18.25.53Et en sortie mes trames ne sont toujours pas correctement formatées en JSON
{ "Time": "2023-03-01T18:28:15", "ENERGY": { "TotalStartTime": "2023-03-01T18:17:53", "Total": 14538.407, "Yesterday": 0, "Today": 0, "Period": 0, "Power": 153, "ApparentPower": 237, "ReactivePower": 181, "Factor": 0.65, "Voltage": 237, "Current": 1, "Load": 3 }, "TIC": { "VTIC": 2, "NGTF": "TEMPO", "EAST": 14538407, "EASF01": 12734205, "EASF02": 1714927, "EASF04": 38258, "EASF05": 15195, "EASF07": 0, "EASF09": 0, "EASF10": 0, "EASD04": 2593655, "IRMS1": 1, "URMS1": 237, "PREF": 6, "PCOUP": 6, "SMAXSN": 287, "PRM": 2147483647, "RELAIS": 0, "NTARF": 6, "NJOURF": 0, "NJOURF+1": 0, "LTARF": "HP ROUGE", "EASF03": 29956, "EASF06": 5866, "EASD01": 7258333, "EASD02": 3482724, "EASD03": 1203695, "SINSTS": 153, "SMAXSN-1": 2494, "UMOY1": 231, "DPM2": 0, "P@OINTE": "000040 5 06004006 2"004005 NONUTILE NONUTILE NONUTILE NONETILE NONUTILE NONUTILE NONUTILE NONUTILE", "ADSC": "031662280532", "STGE": "83DAD401", "FPM2": 0, "EASF08": 0, "CINSTS": 156 } }J'ai vu qu'une API HTTP existe depuis l'interface web mais je ne trouve pas comment elle fonctionne ... tu aurais une idée ?
-
En tout cas la situation s'est améliorée, mais j'ai effectivement ce matin une nouvelle trame corrompue.
Vu que les tags semblent se créer tout seuls à leur découverte, je suppose que mon dernier tag est lié à un problème de mauvaise réception ou de débordement de buffer.
Ne faudrait il pas avoir un dictionnaire des tags valides afin de rejeter les mauvais?
Une autre hypothèse vérifer que les tags reçus sont dans la table ASCII?
07:17:45.160 MQT: tele/Linky/SENSOR = {"TIC":{"ADSC":"022276116693","VTIC":2,"NGTF":"TEMPO","LTARF":"HP ROUGE","EAST":1316060,"EASF01":918154,"EASF02":108799,"EASF03":121563,"EASF04":122694,"EASF05":28448,"EASF06":16402,"EASF07":0,"EASF08":0,"EASF09":0,"EASF10":0,"EASD01":1068165,"EASD02":247895,"EASD03":0,"EASD04":0,"IRMS1":1,"IRMS2":0,"IRMS3":1,"URMS1":237,"URMS2":238,"URMS3":238,"PREF":12,"PCOUP":12,"SINSTS":408,"SINSTS1":207,"SINSTS2":42,"SINSTS3":159,"SMAXSN":7100,"SMAXSN1":2610,"SMAXSN2":2140,"SMAXSN3":2350,"SMAXSN-1":7010,"SMAXSN1-1":2560,"SMAXSN2-1":2080,"SMAXSN3-1":2490,"CCASN":578,"CCASN-1":316,"UMOY1":236,"UMOY2":238,"UMOY3":237,"STGE":"833A5401","DPM2":0,"FPM2":0,"PRM":2147483647,"RELAIS":0,"NTARF":6,"NJOURF":0,"NJOURF+1":0,"SINSS":605}}Bonne Journée à tous
-
@labu73 merci pour ta réponse !
En consultant le forum, je me rend compte que je rencontre exactement le même problème que @Samquad "Tasmota sensor 12.1.1.2 avec linky mode Standard --> Libteleinfo checkline error checksum..." et qui malheureusement n'a pas trouvé de solution et/ou explication au dysfonctionnement ... -
Ne faudrait il pas avoir un dictionnaire des tags valides afin de rejeter les mauvais?
Oui ce serait une solution mais il faut tous les lister et les rentrer. Mais normalement les TAG sont vérifiés avec la checksum avant sauvegarde en mémoire et sont vérifiés à nouveau lors de l'envoi (le fix de ce W.E.) donc je ne comprends pas comment c'est possible ou par le plus grand des malheurs parfois une mauvaise étiquette à une bonne cheksum.
Une autre hypothèse vérifier que les tags reçus sont dans la table ASCII?
Correct ça peut être une vérification supplémentaire, il faudrait que j'ajoute lors de l'envoi un scan des mauvaises (selon ces 2 principes) pour les supprimer de la liste aussi mais j'ai pas eu le temps ce W.E.
Une autre idée serait de tester sur la même installation le Firmware de @Nicolas-Bernaerts aussi pour voir comment ça se comporte.
Pour info depuis que j'ai les stats j'ai aussi quelques erreurs parfois, regarde en 48H
671 erreurs de checksum sachant qu'il y a 256 possibilité de checksum différentes et que seul 64 sont valides (de mémoire) il y a effectivement possibilité de tomber sur une valide de temps en temps ce qui pourrait expliquer simplement sans forcement de bug dans le code, intéressant
-
@NPO il y a 2 soucis en fait, parfois les Linky sont plus ou moins sensibles et certains nécessitent une correction de résistance sur la carte (les prochains batch ont un potentiomètre pour pallier directement)
Tu peux vérifier aussi avec les soft de test de la libteleinfo pour voir si tes trames sont cohérente dans un 1er temps.
-
Pour info j'ai encore ajouté des checks supplémentaires de caractères valides avec cette PR tu me diras si c'est mieux ?
version ESP32 en attendant le prochain autobuild firmware.bin.zip
-
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.
-
Installée, je vais voir ce que cela donne mais 2 bad checksums par trame.
Par contre les trames sont correctes en json.
J'a remis en Skip 0 pour forcer le trait avec une trame toutes les 5s, a suivre pour voir si le problème réapparait.
-
@Charles Merci pour tes réponses; au risque de passer pour un idiot
pourrais tu me dire quel sketch utiliser pour les tests de trames ? Merci -
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.
-
@Charles en faisant marcher ma tête; ça n'arrive pas souvent mais comme quoi ... j'ai ajouté une résistance; de 100 ohm environ; branchée série sur la sortie TIC du compteur et le miracle apparu
Tout fonctionne depuis plusieurs heures de manière stable. En sortie forcement le JSON est correctement formaté !
Par contre il reste une question en suspens ... comment fonctionne l'API ? j'ai beau chercher sur la doc je n'arrive pas à la faire fonctionner ... -
@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
-
@NPO mais t'es un génie, je suis trop jaloux de ne pas y avoir pensé !!
Bien sur le plus simple pour l'augmenter et d'en mettre une en série (et au début fallait la diminuer donc pas possible si simplement) et le plus simple est d'en mettre une avant, très bien joué et en plus ca conforte nos expériences, en standard il faut l'augmenter d'ou le potentiomètre de 1K qui sera sur toutes les prochaines séries (déjà sur le Denky et MicroTeleinfo V3) en lieu et place de la 220 Ohm, merci du retour.
Pour l'API tu dois utiliser MQTT ou faire des WEBPost depuis tasmota vers ta cible, tu peux faire tout ça très simplement avec un script Berry si t'es en ESP32 sinon avec des command
WebQueryavec des rules (moins fun que le Berry) -
@FredLo merci du retour, je viens de regarder j'ai ça en 3 Jours
Effectivement sur 2000 erreurs statistiquement la possibilité d'en avoir une bonne (1/64) et valide et pour moi depuis le debut le soucis est là.
D'ailleur ma trame MQTT ne contient pas d'étiquette chelou donc la vérification implémentée semble être assez efficace, surtout que le JSON sera toujours valide (faut peut être mais valide)
le code source que j'ai relu incluait ta dernière Pull Request qui n'est pas encore dans le build officiel
Si dans celui là (version teleinfo), car il ne sera jamais dans l'officiel la Teleinfo.
-
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.
-
Un petit bilan après 3 jours.
A noter que les 2 erreurs systématiques n'ont toujours pas causé de trames json incohérentes. A part le nombre d'errerus checksum, cela semble bon.
Bonne Journée
-
@labu73 tu as quand même pas mal d'erreurs de checksum, une petite resistance de 1K en série avec ta teleinfo devrait y faire le plus grand bien
j'étais environ à 30/heure à la 220 Ohm et maintenant je suis à 10/heure (j'ai changé par une 1K) je vais augmenter pour voir
-
@Charles
Bonsoir,Tu as surement raison, il faut dire qu'une dizaine de mêtres d'un câble quelconque qui chemine au milieu de toutes les connexions de mon tableau principal, c'est pas idéal.
En tout cas, le remède a été efficace, plus de corruption MQTT.
Par contre, le côté systématique de 2 checksum par trame systématiques avec le dernier Firmware alors que sur l'avant dernier il y en avait peu me surprends.
Merci de ton aide et tes conseils
