@Charles
le Noeud MQTT in de node red reçoit bien la trame en entier quand l'option energyconfig changed est activée.
617f9a8f-f18d-457a-9cf8-ad14cf0a882f-image.png
trame reçue avec option changed
0d4c73bd-3091-40d3-9e54-70e6977e81f8-image.png

Quand energyconfig full est activé la trame est tronquée par le noeud MQTT in😠
cbb20c46-05d3-4fc2-9f11-2a36e8c69cb5-image.png

--> La limitation semble provenir du noeud MQTT in dans Node red.

Si je colle la trame full dans le noeud inject je la visualise en entier dans un noeud debug msg.payload
49281e9e-e8f4-499f-ba13-59c696abb8f7-image.png
04ac533f-2107-4814-85db-bd654f3b6d57-image.png
Pour compiler mes données pour domoticz j'ai besoin de recevoir les données qui changent mais aussi les autres sur lesquels j'ai des conditions.

Est-ce que tu peux m'aider à créer un Rule dans tamsota pour envoyer une trame mqt: tele/Teleinfo/SENSORperso limitée à ces données:

SINSTS puissance apparante soutirée
EASF01 index comptage soutiré
IRMS1 courant instantané
EAIT index compteur production
SINSTI puissance apparente injectée

Je ne sais pas comment écrire cette rule mais je pense que c'est peut-etre possible et que ça pourrait servir à beaucoup d'entre nous😉

merci

Après un bon moment d'acharnement, je me retrouve à n'avoir plus qu'une déception : Je ne sais pas ce qui fait qu'à présent c'est opérationnel 🙂 (En regardant les précédentes photos, j'ai l'impression que mon connecteur de signal sur le module PitInfo n'était pas sur la bonne borne 😑 )

Je vais tenter de faire un second montage avec un Wemos-teleInfo histoire de rendre mon montage plus propre et retenter l'aventure avec un autre D1 mini ESP32 (Il y en avait 3 dans ma commande).

Bref, une étape transitoire où je te remercie grandement @Charles.

Pour ceux qui sont interressés, j'ai ajouté à mon croquis .ino un envoi put à un WS qui stock mes datas en Bdd toutes les minutes. La prochaine étape sera de produire de belles courbes par visu web et surtout alimenter mes relais en fonction de ma production solaire ! (Mais, ça, c'est encore une autre histoire)

@doul59 si il devraient, quand le code aura été adapté 🙂

@titimoby tu as un ballon d'eau chaude ou autre ? en tout cas ça me semble bien une boulette, il faudrait voir ou arrivent ces fils, et surtout attention faudrait pas qu'il y en ai un avec a phase/neutre dessus fais attention.

Bonjour @Charles

eut être demander à l'auteur ou dans le forum dédié.

comprend plus, quelle forum dédié ??

fil conducteur

autres http://vesta.homelinux.free.fr/v/wiki/demodulateur_teleinformation_edf.html

oui après je post sur le
Forum MySensors

et ferai un retour Ici des Infos et finalité du projet

merci de ton aide et bonne semaine ☀

Interressant
je vais essayer de comprendre pourquoi il faut quelque chose de plus compliqué que ce à quoi je pensais (et que je n'ai toujours pa eu le temps de tester)

Bonjour @Vincent-TRUMPFF

C'est Eagle CAD qui été utilisé pour le design. Pour les fabricants ça varie j'en teste plusieurs (SeeedStudio, OceanSmile, JLCPCB, ....)

@Charles J'ai repris ton flow avec les 'convertiretiquettes' un peu modifié.
j'envoie toutes les deux secondes la PAPP.

J'ai vu par ailleurs que meme le cablage et les différents equipements branchés éteints pouvait justifier les 500VA minimum de puissance apparente sur le linky sans consommation réelle pour autant.

Ce qui me parait plus bizarre c'est que sur les pics, on "aurait" une puissance active superieure à la puissance apparente. La je pense que c'est un pb de calibrage.

Aymeric

@yannlieb un grand merci pour ce retour.

@nicoch2i yes dans le pire des cas moins de 1.5mA

3.3V/3.3K = 1mA + 3.3V/10K = 333uA

Ca devrait aller je pense 🙂

@Leopol Désolé je ne connais pas du tout HA, je ne pourrais pas d'aider sur le sujet.

@Géryko Super si ça répond alors, pas programmeur mais tu maitrises les callback, respect, en C en plus c'est le plus fun 🙂

j'imagine qu'elles sont en mémoire dans mon ESP32

Oui mais seulement les valeurs de la dernière trame reçue, en gros tu as toujours les dernières données à jour.

J'ai découvert Tasmota mais aucune expérience à ce jour.

C'est surpuissant mais j'avoue faut un peu le permis de vol, mais la doc est plutôt bonne, faut juste se la taper et c'est pas toujours intuitif

@Bertrand-Docquois

je pense que energyconfig noraw devrait faire l'affaire.
https://tasmota.github.io/docs/Teleinfo/#configuring-teleinfo

Mais attention tu vas quand même recevoir la télémétrie toutes les x secondes

menu configuration -> configure logging -> telemetry period

@Nicolas-Bernaerts merci, ça a l'air intéressant. Il s'agit d'adapter ici Tasmota au matériel Remora qui comporte : la gestion des fils pilotes, le retour de la teleinfo depuis le compteur et la possibilité de commander un relais pour la mise en route d'un cumulus par exemple. Je n'ai personnellement pas l'usage de coupler mes fils pilote à un thermostat, mais je garde le lien , sait-on jamais.

@zethis ah yes oui branché sur les bonnes bornes c'est mieux hein 🙂
en même temps I1/I2 appuyer au tournevis sur le rectangle orange ça ne s'invente pas non plus quelle galère la 1ere fois

PS : Pour les autres users, sur la photo ce n'est pas le bon branchement c'est l'exemple à ne pas suivre hein, je précise au cas ou

@Maxime-CHARDIN Yes tu utilises un truc que j'ai du commencer à écrire il y a 10 ans, respect 🙂

Tu dois pouvoir mettre un compteur pour par exemple n'envoyer qu'une trame sur 10 (c'est arbitraire) mais si tu tournes sur un PI par exemple le mieux et de faire un script python ou utiliser node red pour réaliser tes injections en base moins souvent sans avoir à recompiler le daemon.

@sam-plaibien J'utilise plus que Visual Studio Code avec le plug ins platformio, comme de plus en plus de personnes d'ailleurs.

@Géryko Oui dans la librairie tous les champs sont traité en mode natif, c'est à dire des char, après sur l'affichage ou autre il faut faire du spécifique cf
https://github.com/hallard/LibTeleinfo/issues/22

Bonjour à tous,

Retour d'expérience.
J'étais surpris de voir que l'auteur du sujet dans 'Démystifier le décodage Téléinformation et l’optocoupleur SFH620"
http://hallard.me/demystifier-la-teleinfo/
attachait beaucoup d'importance à R1 et R2, très peu à R3. L'article est toutefois très bien et je le félicite.

Je considère que c'est surtout R1 et R3 qui sont les valeurs critiques de ce montage. R2 ne l'est pas.
Je viens de faire quelques mesures et tests pour évaluer la plage de fonctionnement du montage en faisant varier les tensions.
J'ai la plage la plus large pour R1 = 2700 Ohms et R3 = 6900 Ohms (R2 = 10 K fixe) transistor BS170 opto 814.
Les valeurs préconisées sont donc convenables mais ne pas s'en écarter dans le mauvais sens.
Soient R1 = 2700 et R3 = 8200 en valeurs classiques normalisées.

Nota 1 : grosse surprise dans l'utilisation de transistors BS170. Les 3 bornes étaient inversées !
J'ai vérifié avec un montage précédent que j'avais réalisé en 2017. C'est différent.
J'ai vérifié les datasheets.
Mes transistors sont marqués BS170 et il faut les connecter comme les 2N7000 !
Qu'on se le dise.

Nota 2 :
[On peut voir sur le site de Charles que le potentiel de l'entrée opto est flottante sur l'oscillo.
Il aurait fallu la référencer au 0V (GND de l'oscillo) c'est à dire mettre une patte à GND]

A+