Message reset
-
Bonjour,
J'utilise le shield teleinfo (v1.1) depuis des années avec tasmota sur un esp8266 (wemos d1 mini) et ça fonctionne très bien. J'ai voulu passer sur la version modifiée de Nicolas mais impossible d'avoir un module fonctionnel.
J'ai des centaines de "message reset" par seconde, parfois une ou deux trames en erreur, et au bout d'un moment tasmota finit par planter en boucle avec des exceptions et par virer la conf et la corrompre (si je réactive la réception, ça ne fonctionne plus, il faut que j'efface la conf complètement).
Si je reviens sur le tasmota d'origine avec ma conf habituelle, ça refonctionne nickel.
Mon linky est paramétré en mode standard et l'abonnement est en triphasé. Peut-être une piste : je réside en Corse (donc c'est EDF SEI et pas ENEDIS mais je doute quand même un peu qu'ils aient modifié le protocole TIC).
Est-ce que vous auriez une idée pour comprendre d'où vient le souci ?
-
@raoul Cela ressemble à une vitesse mal configurée.
Avez vous fait un reset complet de la configuration lors du flash de mon fork ?
Est-ce que la vitesse est bien configurée à Mode Standard dans Configuration / Teleinfo ? -
@Nicolas-Bernaerts oui j'ai fait un reset 6 la première fois. J'ai même passé un coup d'esptool erase-flash sur certains essais.
Pour la vitesse, la détection auto ne fonctionne pas donc oui, c'est paramétré en mode standard.
J'ai vu que vous avez codé un petit serveur TCP pour avoir un log des trames. J'avais dans l'idée de le backport dans la version d'origine afin de pouvoir comparer les trames reçues (j'ai été développeur C dans une autre vie). En préparant ça, j'ai remarqué que dans votre code, l'init de TasmotaSerial n'est pas appelée de la même manière pour les esp8266. Dans la version de Charles, le paramètre hardware_fallback vaut 2.
Tada !!!
Ca marche instantanément quand ce paramètre vaut deux !
-
-
@raoul J'ai uploadé une version esp8266 4M basée sur Tasmota 15 qui intègre le correctif.
Pourriez-vous tester pour confirmer que c'est réglé ? -
@Nicolas-Bernaerts c'est bizarre. J'ai chargé le firmware (OTA), ça semble ne pas être stable. L'esp perd pas mal de paquets au niveau réseau, et home assistant ne se met plus à jour. Je suis revenu à ma version, ça fonctionne bien à nouveau. J'ai reuploadé la vôtre, rebelote pertes de paquets, et plus de maj dans ha. Par contre au niveau de l'interface web tasmota ça se met bien à jour régulièrement et il n'y a plus d'erreurs.
-
@raoul Comment avez vous déterminé qu'il y a des pertes de paquets ?
(sur un D1 mini Pro 16 Mb je n'ai aucune erreur de réception en mode standard)
Si l'interface Web de tasmota se met à jour sans erreur cela signifie que la réception est stable. Le problème est sans doute ailleurs.
Il est à noter que l'intégration Home Assistant de mon fork n'est pas basée sur l'auto-discovery Tasmota mais sur un auto-discovery MQTT natif. Il faut donc rechercher le device dans les devices MQTT. Vous aurez beaucoup plus de données publiées que les données standard de Tasmota. -
@Nicolas-Bernaerts avec un ping tout simple. L'esp cesse de répondre par moment pendant 20-30s comme s'il perdait le réseau. Il manque pas mal de ping même sans ça, sans qu'il y ait un pattern évident. Il ne reboot pas par contre. Je n'ai pas eu le temps d'investiguer aujourd'hui mais j'essaierai de compiler votre dernier commit demain matin pour confirmer que je reproduis bien. Il faut toujours partir du code de la 15.0.1 ?
-
@raoul Mon fork demande beaucoup plus au CPU que la version d'origine. En effet, toutes les fonctions et intégrations sont demandeuses en particulier en terme réseau. C'est d'autant plus le cas si la réception wifi n'est pas nickel.
L'esp8266 étant un mono coeur, la gestion réseau et la réception teleinfo sont partagées sur le même coeur. Vous êtes clairement aux limites des possibilités du CPU. Il est normal qu'une sollicitation réseau externe soit dépriorisée. Essayez un esp32 et vous verrez que tout devient fluide. -
@Nicolas-Bernaerts je comprends. Disons qu'avec votre dernier commit, c'est en train de devenir inutilisable sur un esp8266. C'est dommage. J'ai comparé ce matin entre la version que j'ai compilé avec vos sources d'il y a une semaine et les actuelles, dans le premier cas j'ai 5% de loss sur le ping, dans le second 20% (sur 1000 pings). Dans le premier les infos remontent correctement dans ha, dans le second quasiment plus. Je vais rester sur votre ancienne version en changeant juste l'init de TasmotaSerial pour le moment.
En tout cas super boulot. C'est top d'avoir le cos phi en temps réel ! un grand merci !
-
@raoul C'est très etonnant car j'ai juste fait un refactoring du code pour éviter les modules multiples. Coté performances, cela devrait être totalement neutre.
Voici un ping réalisé ce matin sur un module esp8266 16M avec une alimentation Triphasé standard. Le ping répond plutôt très bien malgré un wifi moyen.
Il doit sans doute y avoir un autre problème.Vous avez bien activé uniquement l'émission tous les +/- xxx W ?
-
@Nicolas-Bernaerts Oui j'ai fait un test en essayant l'alléger la charge, sans résultat (sachant qu'avec mon build, j'ai paramétré une transmission à chaque trame).
J'ai voulu faire un build avec vos dernières sources afin de voir. Il a fallu que je réintègre esp_timer_get_time mais je vous confirme que j'arrive bien à reproduire le souci avec ces sources. Je vais continuer à investiguer demain pour voir si j'arrive à mettre le doigt sur ce qui cause ce comportement.
-
@raoul Un esp8266 ne peut pas tenir la charge de publication à chaque trame en mode standard (c'est quasiment toutes les secondes). Decochez toutes les options de publication et sélectionnez "à chaque télémétrie" en sélectionnant une période de télémétrie supérieure à 10s. Vous devriez retrouver un esp réactif.
Même pour un esp32, la publication à chaque trame est très stressante. Je le précise et le déconseille fortement sur ma page github.
De mémoire, le build officiel impose une publication toutes les 10 s maximum ...
-
@Nicolas-Bernaerts oui j'ai bien lu votre page et j'ai précisé que j'avais fait le test aussi en réduisant la charge. Le problème ne peut pas venir de là puisqu'à configuration identique, ça fonctionne bien avec un firmware et pas avec l'autre. L'élément variant entre un module fonctionnel et un module qui ne l'est pas est le code, pas la conf. Donc ça vient forcément du code.
J'ai vu plusieurs problèmes ce matin. TeleinfoDriverEvery250ms n'est plus appelée pour commencer. Ensuite il y a un problème de logique avec teleinfo.hass.stage. Une fois qu'elle vaut UINT8_MAX, il n'y a rien pour la faire revenir à une valeur de publication (ou en tout cas je n'ai pas compris comment). La version d'avant était déjà concernée par ce problème.
Alors ça n'explique pas la dégradation sur la communication réseau mais c'est déjà un bout d'explication sur la partie communication data.
-
@raoul Good shot !
Effectivement je n'avais pas porté l'appel de TeleinfoDriverEvery250ms dans le refactoring. Je viens de publier une version esp8266 4M intégrant la correction.
Concernant HASS, c'est logique car la déclaration n'est faite qu'une seule fois au boot en mode persistant. Ce sont ensuite les étiquettes "Consommation & Production" qui sont exploitées par HASS.
Le refactoring étant en cours, vous êtes en fait un beta testeur
-
@Nicolas-Bernaerts Ravi d'avoir pu contribuer un peu
Je suis toujours perplexe sur l'histoire des pings. Je vais lancer des tests sur 12h histoire d'avoir quelque chose de significatif pour confirmer/infirmer. Je vous tiens au courant. -
@Nicolas-Bernaerts le problème sur le réseau est aussi résolu. Avant / après j'ai à peu près 7% de pertes sur les pings. A noter qu'en désactivant juste l'appel aux fonctions pour les relais virtuels, les pertes tombent à 2%. Ce serait peut-être intéressant de pouvoir désactiver des fonctionnalités pour ceux qui souhaitent juste collecter / calculer des infos à partir du linky et les transmettre.
