@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

@sebh said in Tasmota:

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

@sebh said in Tasmota:

Tu choisis la pin D7, il reboote,

Ca c'est normal. Quand tu appliques une config de GPIO et que tu cliques "SAVE", Tasmota reboote

Si tu vas vérifier la config juste après le reboot, est que D7 est toujours configurée en Teleinfo ?

Peux tu te mettre en WebLog 3 avant d'appliquer la config sur D7, puis après le reboot copier ici les premières lignes du log, jusqu'à la connexion WIFI, cela suffira

Quoi que là, ton log semble vouloir dire qu'il y a eu un crash
J'essayerais demain soir. Pour l'instant game-over
Bonne nuit

@Charles Tu es sur Discord ? Ca serait plus simple d'en chatter en live

Mais les driver xnrg_xx sont des ous drivers de xdrv_03_energy
xdrv_03_energy decode les commandes liées à l'energie (voir au debut du module) et passe au sous driver uniquement ces commandes là

Je suis en train de discuter sur le discord de l'equipe pour voir les options possibles

@barbu-dor My bad, tu as deja XNRG_15 15 au debut (tu es un driver NRG, pas un driver générique)

Et les drivers energy ne peuvent pas recevoir de commandes individuelles mais uniquement les commandes standards energy

Donc c'est pour cela que tu ne reçoit pas les commandes