@lebphi Peut être un pb de fiabilité du hard alors ?
Essaye d'effacer et reflasher le D1
As tu une bonne alim ?
C'est un lolin original ou un clone ?
Rien d'autre que l'interface teleinfo dessus ?
Qu'as tu comme messages dans la console quand ca décroche ?
Bonjour @lebphi
Tasmota est avant tout fait pour fonctionner en MQTT. L'API http peut permettre de passer des commandes de temps en temps mais poller continuellement l'état des senseurs par http soumet Tasmota a du stress.
Par exemple, l'appli TasmoAdmin qui permet de surveiller un ensemble de Tasmota fonctionne par http et elle est connue pour mettre à mal Tasmota. Elle est fortement déconseillée.
Donc il est fort possible qu'une fuite mémoire finesse par casser quelque chose.
Je vais jeter un coup d'oeil pour voir si j'arrive a reproduire mais pas sur que ca soit facile a régler.
Si tu ne veux absolument pas passer à MQTT, qui est aujourd'hui "LE" standard en domotique, tu peux essayer de fonctionner à l'inverse avec un règle pour publier vers jeedom avec un WebSend. Certaines personnes font cela avec emoncms.
Par exemple: https://github.com/arendst/Tasmota/discussions/11101#discussioncomment-651394
@vincent835 OK
En tout cas je trouve la forme avec l'object TIC plus propre que d'avoir tout a plat
@vincent835
Si
MQT: tele/tasmota_DF20CB/SENSOR = {"Time":"2021-04-10T19:49:06","TIC":{"ADSC":"031776013513", ....
les champs sont sous l'object TIC alors => on TIC#URMS1 do ...
Si
tele/tasmota_DF20CB/RESULT = { "ADSC":"031776013513","VTIC":2,"NGTF":" BASE " ....
Les champs sont a la racinedu JSON alors => on URMS1 do ... (ou bien on URMS1#data do .... )
Je ne me rappelle jamais la règle exacte quand il faut ajouter #data pour un champ à la racine. Je crois que c'est quand il est orphelin mais dans si le 1er ne marche pas essaye le 2nd
Si ca ne marche pas il faudra que je remonte une manip de test
@vincent835
Par rapport au message SENSOR que tu postes il manque le niveau TIC
Donc le trigger est TIC#URMS1 et la règle correspondante
rule1 on TIC#URMS1 do var4 %value%
Le message a t'il un format différent entre les 2 versions ?
@charles Page de doc créée
https://github.com/tasmota/docs/blob/development/docs/Teleinfo.md
Pour la mise a jour, comme pour le code, soit tu fork, tu clones, tu PR
Ou alors directement en ligne dans GitHub (GitHUb fork et crée les branches et PR automatiquement)
Attention MKDOCS demande une syntaxe de markdown un peu particulière et la preview de GitHub n'est pas forcément correcte.
Tagguer quand tu aurs fait la PR pour que je vérifie (j'ai les outils mkdocs pour vérifier)
La page est dans la branche développement car elle se rapporte a des modifications disponibles dans la branche développement de Tasmota. Donc elle n'est pas visible autrement que sur GitHb (la doc publiée est celle de la release).
Elle passera en master quand la 9.3 sortira (avant fin avril)
@vincent835 Compte tenu que j'ai posté ce message le 11 février et que la 9.3.1 est sortie le 22 février, ma PR de février est donc dans le code de la release 9.3.1
MAIS n'oublie pas que Teleinfo n'est pas inclus par défaut dans aucun des binaires et qu'il faut compiler soit même.
Donc tant qu'a compiler, autant le faire sur la version de développement.
@charles Super 
Est-ce que les settings sont sauvegardés ?
Ou bien faut-il les remettre à chaque démarrage ?
C'est assez facile soit avec une Rule type
on system#boot do backlog EnergyConfig xxxx; EnergyConfig xxx endon
De plus maintenant en activant le FileSystem en flash on peut aussi avoir un fichier `autexec.bat' 
qui enchaîne des commandes de configuration. Même sur un module minimum de 1MB on peut avoir 48kB de filesystem, largement suffisant pour un autoexec.bet conséquent. Avec un MiniD1/NodeMCU de 4MB on peut avoir 2MB de filesystem.
Sur ESP32, la place réservé au code est plus importante (2 * 1,9MB pour gérer l'OTA) et donc le filesystem minimum est de 48kB aussi.
Ca serait bien de faire une page de doc dédiée mais par contre, il faudra la faire en anglais pour être cohérent avec le reste. Je peux regarder cela un peu plus tard.
@charles Theo vient de merger ma PR
Il y a maintenant une commande EnergyConfig qui est poussée jusqu'au driver energie actif
A partir de là tu peux traite la commande comme tu veux (la chaine est dans XDrvMailbox.data)
Regarde le petit exemple ajouté dans xnrg_20_dummy
00:00:00.039 TIC: RX on GPIO13, baudrate 9600
00:00:00.039 TIC: always enabled
00:00:00.090 SNS: Hardware Serial
00:00:00.090 TIC: using hardware serial
00:00:00.090 TIC: Ready
Pourtant le module Teleinfo (TIC) est bien démarré et sur la GPIO13 (D7)
Donc a ce moment là il devrait être en mesure de recevoir
Par contre le dernier redémarrage est quand même du à un crash
Il faudra que j'essaye ce soir