@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.

@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 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.

@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.

@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 !

@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 ?

@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.

@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 !

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 ?