Bonjour @akim
J'ai les composants dans une boite mais pas eu le temps encore de monter la manip.
Le principe que je veux tester c'est:

• Un redresseur a base de diodes shotky type BAT54
• Des super caps (j'ai acheté des super caps 30F/2.7V chez AliEx, je compte en mettre 4 en série pour atteindre 10V de tension de fonctionnement ce qui devrait aller avec la sortie de l'alim en charge)
• Derrière, un régulateur 3.3V ou 3.0V
• Un ESP en utilisant le mode Deepsleep pour ne faire qu'une mesure toute les 1 minutes

Le principe est d'accumuler l'énergie dans les super caps pendant que l'ESP est en veille (<50µA), et de puiser dans les super caps durant les 15 secondes nécessaires a la mesure, la connection WIfi et la publication MQTT (~ 200..400mA)

Avec max 35mA disponible sur l'alimentation, impossible de faire tourner un chip Wifi en continu.
L'alternative serait avec du Bluetooth.
Dans ce cas, un module téléinfo => série vers un module bluetooth (HM-10 par ex) préconfiguré devrait passer en continue avec un portée d'une dizaine de metres.
Un PC ou RPi avec bluetooth pour récupérer en port COM virtuel.

Supercap 30F/2.7V : ali express /item/1005001555799773.html

@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