@BRENY00 Le compteur opérateur est très fiable, mais c'est vrai que moi aussi j'aimerais plus de précision sur l'ampérage, à une époque je faisais de manière empirique en prenant I = Puissance / Tension (mais vous n'avez peut être pas l'étiquette TENSION
Bonjour @beneva,
Vous avez un contrat spécifique (BBR) et de mémoire ce type de contrat n'est pas géré en mode historique dans Tasmota. Si vous avez un Linky et que vous le faites passer en mode Standard ça marchera.
Cordialement
@Gérard-Rotschi tu es tout bon, tu pouvais même utiliser l'autoconf pour que ça mette le bon template et paramètres directement.
@ellipsis sorry about that, I though you wanted Denky to communicate thru PI using WiFi (both on same network) and sending data to PI MQTT broker using the network.
To have the linky physically connected to PI you should have used PITinfo (PI Connector) or MicroTeleinfo (USB). MicroTeleinfo is better if you want to connect several dongle to same PI (up to 4 USB)
Anyway you can use Denky D4 to do the same thing but it's a little overkill, you can try to flash some sample to read teleinfo from denky and send thru Serial.
https://github.com/hallard/LibTeleinfo/tree/master/examples/Teleinfo_DenkyD4
Check ou samples Teleinfo_DenkyD4 or ESP32_Passthru (this one more like MicroTeleinfo or PiTinfo)
But I repeat easier and fasted way is to connect Denky D4 with WiFi and Tasmota firmware and then send data to MQTT.
You can also set picocom to 115200 (to see tasmota log and extract ENERGY frame data)
Et d'ailleurs on peux faire soit même des pull request pour corriger des bugs de se style ? ou ca doit passer par toi ?
Absolument pas tout le monde peut faire des PR dans tasmota, j'ai tout ce qu'il faut sous la main et l'habitude ça m'a pris 2 min mais la 1ere fois chaud, faut avoir un fork, le maintenir en sync faire une branche et la merger, et parfois des rebase, le process est lourd au début mais si tu maitrises git aucun soucis (c'était pas mon cas et ça l'est pas toujours)
@Pi57 c'est exactement ça et c'est pour ça que tu n'as que des checksum errors et pas d'autres. Il faut que j'ajoute ce caractère, j'ai cherché tous ceux autorisés dans la spécification mais je n'ai pas trouvé.
En l'état aucun soucis pour toi, juste tu ne peux pas avoir cette étiquette retournée en attendant le fix mergé
En tous cas merci pour avoir trouvé le bug
@Pi57 je pense que tu as le firmware avec le fix codé trop rapidement (toutes les checksum à 0) peux tu installer la dernière version dispo ici ?
Tu as quoi comme carte ?
@labu73 tu as quand même pas mal d'erreurs de checksum, une petite resistance de 1K en série avec ta teleinfo devrait y faire le plus grand bien 
j'étais environ à 30/heure à la 220 Ohm et maintenant je suis à 10/heure (j'ai changé par une 1K) je vais augmenter pour voir
@Nicolas-Bernaerts Merci du retour, effectivement les étiquettes sont totalement différentes, il faudrait adapter le code car en l'état ça ne fonctionnera pas surtout qu'en plus les formats de transmission semble différents avec cet horodatage.
Donc @lambda2 oui la TIC matérielle est compatible, non le code ne l'est pas, soit il faut l'intégrer par toi même, ou alors utiliser aussi l'excellente version de @Nicolas-Bernaerts comme il l'a indiqué ci dessus.
@FredLo merci du retour, je viens de regarder j'ai ça en 3 Jours
Effectivement sur 2000 erreurs statistiquement la possibilité d'en avoir une bonne (1/64) et valide et pour moi depuis le debut le soucis est là.
D'ailleur ma trame MQTT ne contient pas d'étiquette chelou donc la vérification implémentée semble être assez efficace, surtout que le JSON sera toujours valide (faut peut être mais valide)
le code source que j'ai relu incluait ta dernière Pull Request qui n'est pas encore dans le build officiel
Si dans celui là (version teleinfo), car il ne sera jamais dans l'officiel la Teleinfo.