Teleinfo-TIC-with-ESPhome
Teleinfo-TIC-with-ESPhome copied to clipboard
schmurtzm
BUG avec le TIC (je ne sais pas comment le qualifier)
la lecture du linky a un probleme
sur un autre firmware la lecture se faisait correctement
donc je pense qu'il y a un problème avec le firmware
Hello,
Je pense avoir le même problème.
Au début ca fonctionne correctement puis au bout d'un certain temps variable (entre 10 minutes et 4h ), les données recues deviennes du "garbage"....
Le reste fonctionne correctement. Les données d'uptime ou qualité du wifi sont remontée correctement dans home assistant.
Il faut faire un reset ou débrancher/rebrancher l'arduino pour retrouver un système qui fonctionne parfaitement pendant quelques temps.
Mon arduino est un wemos D1 mini et j'ai essayé de brancher la ligne des données sur plusieurs pin du D1. C'est toujours la meme chose. C'est comme si la vitesse du port serie changeait coté arduino aléatoirement. (style on passe de 1200 bauds a 9600). J'utilise l'adaptateur vendu sur http://hallard.me/
bizarre....
#2 Mon plantage n'est pas exactement au bout de x secondes. Mais j'utilise pour l'instant un esp8266 (D1 mini). Il faut que j'essaie avec un esp32. Le problème avec le 8266 c'est qu'il ne reboot pas tout seul. Il faut une action manuelle. Si ca plante aussi avec l'esp32 mais après plus de temps, ca ressemble à une fuite de mémoire. L'esp32 a plus de mémoire que mon 8266...
Je n’ai pas rencontré ce problème... Le montage tourne bien depuis plusieurs mois. L’esp plante parfois (il doit y avoir une fuite mémoire quelque part dans le code car ça plante toutes les sept heures précisément, mais c’est anodin car l’esp32 reboot en quelques secondes).
Charles Hallard fait super bien les choses en général mais peut-être que l’optocoupleur ne fonctionne pas correctement... @redge76 , tu pourrais lire la ref de l’optocoupleur ? Je sais que sur les anciens modèles de Charles celui-ci posait problème (mais c’est sensé être réglé).
@duncan-valleix tu as le même module toi aussi ?
@schmurtzm j'ai acheté mon adaptateur il y a 2 semaines... je vais essayer avec un esp32 si je trouve le temps.
Sinon quelqu'un connait une solution "facile" pour remonter les données dans home assistant et qui ne plante pas avec un esp8266 ?
Je viens de checker : j’ai bien un wemos D1 moi aussi, pas un esp32... Par contre s’il crash il reboot tout seul et je n’ai jamais observé cette corruption de données. J’ai la version 1.14.4 de esphome (on ne sait jamais desfois que ça jouerait).
Tu as un firmware que j’ai publié dans mes repo mais sincèrement le moyen le plus simple c’est esphome je pense...
J’ai peut-être une piste, peux tu retirer toute les lignes commençant par « ESP_LOGD » dans le fichier my_tic_component.h ?
bonjour, alors a vrai dire j'ai utilisé plusieurs firmware différent donc je n'ai pas retenté l'aventure avec le firmware que tu as crée mais moi le problème était présent des le démarrage, j'ai aussi un Wemos D1 mini, la actuellement je suis avec un firmware sous arduino si besoin je peut testé avec un autre wemos d1mini mais je n'ai pas ce problème de fuite ou lecture incorrecte des données
@redge76 Sinon quelqu'un connait une solution "facile" pour remonter les données dans home assistant et qui ne plante pas avec un esp8266 ?
en solution de dépannage je peut te conseillé sa: https://jbdesbas.wordpress.com/2017/02/25/recuperer-les-informations-du-compteur-edf-avec-un-esp8266/ par contre il te faut un broker MQTT
Bonjour, bon pour reprendre le fonctionnement du code, le bus série est lu pour remplir la chaîne buff. Chaque caractère reçu est d'abord converti en 7bits (parce que sur esphome il n'est pas possible de paramétrer l'uart, il est en 8bits de base). Chaque message est séparé par '\r\n' donc si le caractère lu est '\n' c'est le début d'un message donc on vide le buffer, si c'est '\r' c'est la fin d'un message donc on traite le contenu du buffer. Dans le log on voit bien que les messages sont traités mais qu'ils contiennent n'importe quoi, c'est donc un problème avec les données reçues. Cela peut d'expliquer par un bug du composant uart d'esphome, mais je penche plutôt pour un problème de fuite mémoire. Déjà lors de l'écriture du code, j'ai bien vu que l'utilisation de debug (ESP_LOGD) provoquait des reboot de mon ESP32 assez rapidement (quelques minutes) alors que là par exemple mon uptime est de 22 jours, mais je pense que c'est surtout dû à l'utilisation de la fonction .c_str(). Une amélioration que je vois pour limiter la fuite mémoire serait de ne pas déclarer la string buff à chaque lecture de caractère mais en global.
Donc dans le fichier my_tic_component.h il faut remplacer la ligne 40 dans le fonction update() String buff = ""; par buff = "";
et déclarer la variable buff dans les déclarations du début juste après String adco = ""; String buff = "";
Vous pouvez aussi jouer avec la valeur passée dans PollingComponent(1000), c'est le délai d'appel de la fonction update en millisecondes, 15 ou 60 secondes c'est largement acceptable mais je ne sais pas trop se qu'il se passe avec le buffer série si l'on passe 60 secondes sans le lire...
Bonjour, bon pour reprendre le fonctionnement du code, le bus série est lu pour remplir la chaîne buff. Chaque caractère reçu est d'abord converti en 7bits (parce que sur esphome il n'est pas possible de paramétrer l'uart, il est en 8bits de base). Chaque message est séparé par '\r\n' donc si le caractère lu est '\n' c'est le début d'un message donc on vide le buffer, si c'est '\r' c'est la fin d'un message donc on traite le contenu du buffer. Dans le log on voit bien que les messages sont traités mais qu'ils contiennent n'importe quoi, c'est donc un problème avec les données reçues. Cela peut d'expliquer par un bug du composant uart d'esphome, mais je penche plutôt pour un problème de fuite mémoire. Déjà lors de l'écriture du code, j'ai bien vu que l'utilisation de debug (ESP_LOGD) provoquait des reboot de mon ESP32 assez rapidement (quelques minutes) alors que là par exemple mon uptime est de 22 jours, mais je pense que c'est surtout dû à l'utilisation de la fonction .c_str(). Une amélioration que je vois pour limiter la fuite mémoire serait de ne pas déclarer la string buff à chaque lecture de caractère mais en global.
Donc dans le fichier my_tic_component.h il faut remplacer la ligne 40 dans le fonction update() String buff = ""; par buff = "";
et déclarer la variable buff dans les déclarations du début juste après String adco = ""; String buff = "";
Vous pouvez aussi jouer avec la valeur passée dans PollingComponent(1000), c'est le délai d'appel de la fonction update en millisecondes, 15 ou 60 secondes c'est largement acceptable mais je ne sais pas trop se qu'il se passe avec le buffer série si l'on passe 60 secondes sans le lire...
bonjour, alors je n'ai compétence technique pour validé ton idée mais si tu l'as testé peut tu modif le fichier et si c'est approuvé @schmurtzm fera se qu'il faut pour que les modif apparaisse bien
j'ai une lecture alors que je n'en avais pas avant, en tout cas pas fiable
possible la cause du debug dans le fichier component ? @schmurtzm
je vais teste ta modif @gaelbenoit, c'est bien comme sa que tu le préconise ?
Edit: bon cette modif ne fonctionne pas l'esp démarre mais il execute un soft reset
J'ai le même soucis avec le fichier components d'origine
Bon je suis passé sur un vieux esp8266 lolin . Et ca plante toujours au bout de X minutes ( 20 en moyenne) A+
uart
Hello, j'étais entrain de re-jeter un oeil sur ce problème de stabilité et on dirait qu'une mise à jour de ESPHome permet maintenant de travailler en 7 bits sur l'uart : https://github.com/esphome/feature-requests/issues/304#issuecomment-713598579
Une piste donc pour simplifier et stabiliser d'avantage ce code !
Je rappelle que @gaelbenoit est l'auteur de ce code (et non moi ;) ) . Je le remercie d'ailleurs pour le boulot initial effectué ainsi que sa participation dans les issues ;)
Hello j'ai poussé une nouvelle version qui me parait avoir bien gagné en stabilité : https://github.com/schmurtzm/Teleinfo-TIC-with-ESPhome/commit/3e2799a29d121ead83648cb1954bbf1454e4e47b N'hésitez pas à me faire un retour !
je viens de commencer à la tester, j'ai viré tous les 3 debugs encore actifs, à suivre... pour l'instant uptime = 45min et c'est avec 5 ble_rssi et 3 xiaomi_lywsd03mmc
