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