Je ne suis pas.chez moi pour prendre de photo mais j'ai juste soudé le wemos au teleinfo, pas de façon très propre mais ça marchait il y a quelques mois.

@Obi_Yoann Je viens de déposer une version 11.1 sous https://github.com/NicolasBernaerts/tasmota/tree/master/teleinfo
Evolutions :

Mise à jour dynamique des courbes Compteur Energy Today persistant après reboot

Elle devrait compiler sans soucis.

@Charles Effectivement, en mode historique j'avais des erreurs et en mode standard je n'en ai pas.
Comme tu l'indiques, j'ai lancé la commande energyconfig standard pour changer le mode.
Pour info, le Denky est branché au Linky via un cable type téléphonique long de 15 mètres. Je pense que ça joue un peu sur la qualité de la réception.

Bonjour,

Je me permet de rebondir sur ce sujet ayant été confronté à un problème de bad crc visible sur l'interface web du teleinfo. J'utilise également un Wemos D1 ESP32 avec le TIC v1.1, et pour info je suis en contrat Tempo.

J'ai installé l'ESP via ESPHome pour remontée des infos dans Home Assistant.

J'avais déjà le soucis de bad crc en mode historique et il était toujours présent en mode standard donc je me suis décidé à mettre une résistance de 1k Ohms comme proposé ici, cela semble avoir résolu durablement mon soucis.

J'avais quelques soucis de valeurs incohérentes qui faussaient les stats, à voir si cela règlera également ce problème.

Merci beaucoup pour votre travail et vos conseils.

@Géryko said in Je m'interroge sur les avertissements de dépassement:

Enedis-NOI-CPT_54E-1.pdf

Super, merci à toi, du coups je mets cette courbe ici pour référence.

59cfa09d-99e6-43e1-92c3-fb9df82517c5-image.png

@mathieucarbou il y avait des soucis de mail avec OVH du coups j'ai tout changer maintenant on passe par TipiMail qui à l'air de parfaitement fonctionner.

@Géryko said in MicroTeleInfo V2 - Trames incohérentes:

Bonjour à tous,

Je prends ce sujet au vol, quelque chose m'interpelle.
Ce n'est pas en mesurant des résistances qu'il faut résoudre ce problème.

Tout à fait mais quand le problème n'est pas identifiable (car j'ai installé plus d'une 10zaine de Linky sans jamais le rencontrer) on fait avec ce qu'on a sous la main (le retour utilisateur) et tous les utilisateurs ne sont pas équipés et des pros de l'ocscilloscope (déja avoir un multimètre et savoir mesurer une resistance avec c'est top)

Personnellement, j'ai eu des cas assez bizarres sur l'adaptation compteur/capteur de TIC.
Un montage personnel qui fonctionne très bien à mon domicile avec 50m de câble
ne fonctionne pas chez un ami en utilisant ce même câble !

C'est bien tout le problème avec la TIC, ya une spécification et pourquoi le comportement est différent d'un compteur à l'autre ?

Si le montage comporte un potentiomètre, c'est bien pour effectuer un réglage ?
Comment réglez-vous ce potentiomètre ? (notice - mode d'emploi ?)

Il suffit d'observer les erreurs de checksum et tourner le potentiomètre jusqu'a ce qu'elles disparaissent ou avoir des trames cohérente, mais c'est vrai je vais mettre à jour la documentation.

Il faudrait utiliser un oscillo pour voir le signal en sortie de l'opto coupleur.

Oui tout à fait, quand c'est possible, CF ma remarque si dessus

Sans oscillo, régler en observant la lecture des trames (ou une DEL en sortie du transistor de réception ?)

La DEL est présente sur certains nouveaux modèles notemmment sue le Denky D4 et le MicroTeleinfo V3

Les schémas de ces 2 modules se trouvent-t-ils sur le site de Charles H.?

Ce sont des projets open source tout existe et sur Tindie tous les liens vers la documentation des produis sont indiqués, dans le cas des deux modules présents, c'est ici :

https://github.com/hallard/Denky-D4
https://github.com/hallard/uTeleinfo

@Jo-Desombre il faudrait dans un 1er temps vérifier en manuel (sans HA) et regarder ce que sort le port /dev/ttyACM0

il y a tout un tas d'outils pour cela y compris au plus simple avec la commande de picocom si tenté que le port soit bien le ACM0

picocom -b 9600 -d 7 -p e -f n /dev/tty/ACM0

https://github.com/hallard/python-teleinfo
https://github.com/hallard/teleinfo-test

@Jean-louis je ne sais pas si le total des phases est retourné dans la tic, un debug de trame complète pourrait au moins voir si on l'a mais je n'en suis pas certain.

Sinon il faut le faire soit même avec un script Berry par exemple qui peut tourner sur directement sur Tasmota (si c'est un ESP ESP32) ou à l'arrivée dans HA, mais ça je ne sais pas faire.

@fdaubercy absolument, même méthode que dans ma réponse précédente sur la production, ce doit être faisable avec un script berry qui affiche des valeurs custom. A l'occasion faudra que je teste.

@fdaubercy ok je vois les étiquettes sont très différentes en production et ce n'est pas intégré dans Tasmota.

En revanche tu dois pouvoir afficher les étiquettes que tu souhaites dans l'interface WEB avec Berry et un script qui va bien.

L'exemple ici pour récupérer les valeurs qui t'intéressent puis ici la partie affichage

j'ai jamais testé mais ça correspond à ce que tu veux faire en custom.

@Charles Merci beaucoup.

J'ai un peu galéré (ça n'est pas du tout mon domaine) mais j'ai fini par trouver une solution. Je mets mon code ici car j'ai l'impression que le

light.set({"channels":channels, "bri":64, "power":true})

ne fonctionne pas (il éteint la LED chez moi). J'ai dû "bricoler" pour parvenir à mes fins en utilisant le paramètre (rgb" :

import string def setcolor(iinst, isousc) var red = tasmota.scale_uint(int(iinst), 0, isousc, 0, 255) var green = 255 - red var channels = string.hex(red,2)..string.hex(green,2).."00" light.set({"rgb":channels, "bri":64, "power":true}) #tasmota.set_timer(2000, setcolor) end

Et j'appelle cette fonction depuis "rule_tic".
J'espère que rafraichir aussi fréquemment la LED ne va pas réduire sa durée de vie. J'ai essayé de mettre des "timer" sans succès. On verra bien.

Enjoy !

@Jonathan-Lacroix

voici une super illustration de ce que tu viens d'indiquer

ee31e50e-d099-45ed-9f5a-7ed6bac7d62b-image.png

@Jonathan-Lacroix tu as tout à fait raison, il faut que je regarde ça de plus prêt. @Nicolas-Bernaerts tu as traité ce mode de puissance dans ta version ? si oui on peu s'en inspirer.

Bonjour à tous,
Le binaire n'étant pas créé durant la compilation, je l'ai trouvé sur le site tasmota (ota).
Placé dans le répertoire correct cela résout le problème.

Bonjour à tous,

Je pense avoir trouvé la solution !
La fonction void IRAM_ATTR fonction_ISR() { ... } doit se trouver en amont du setup en non après.

Qu'on se le dise.
ça peut paraitre évident mais ... il faut le savoir et personne n'en parle.
A+

@Charles Hello,
Oulah ! mais tu sais je ne suis pas développeur 🙂
Ca à l'air très intéressant effectivement de faire un script Berry. Si je comprend bien cela permet de sélectionner ce qu'on envoi en mqtt vers le broker, sauf que la partie script en exemple c'est du chinois pour moi et bien que j'en comprenne globalement le sens, je suis incapable de transposer ça pour envoyer uniquement les données que je veux via le topic mqtt vers mosquitto.

Par ailleurs, bizarrement EnergyConfig Skip 0 puis EnergyConfig Changed semble plus lent à être traité que EnergyConfig Skip 20, pourtant je suis sur un matériel assez bien dimensionné. Odroid N2+ 4GO

@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

Ah, et bien super, merci beaucoup pour vos réponses !