@Tristan @Schmurtz Vos commentaires m’éloigne de mes attentions. C 'est pas grave j’ai une alimentation à côté on va continue avec ton firmware en attendant la sortie officiel de esphome pour voir les différences.
Pour l’ESPHome que je ne connais pas bien, avec le Linky je suppose que l’ESP doit être en permanence alimenté afin de lire l’interface série pour récupérer l’ensemble des infos TIC. Donc je ne vois pas bien comment cela peut fonctionner avec une batterie/pile sur une grande période (1 an).
Ah génial ! @Tristan, merci de ton passage par ici ! J’ai vraiment apprécié tes articles (il devrait y en avoir plus ! 
), super intéressants et merci d’ailleurs pour le partage !
Concernant l’alim je me posais la question de comment tu obtenais les 5v car à la sortie de mon pont de diode j’ai 13-14v, ce qui me parait logique car en sortie du pont de diode on est sensé avoir une tension plus élevée , non ? (x1.41 de ce que j’ai pu lire). Ce qui est embêtant du coup car avec 13-14v je n’ai pas intérêt à y mettre mon AMS1117 
Ouep 39mA… C’est pas grand chose… L’idée des « super capacité » me plais, il faudrait faire le calcul pour savoir pendant combien de temps un ESP pourrait être alimenté avec ce mode de fonctionnement. Aura-t-il suffisamment de temps pour écouter son interface série durant tout un cycle d’envoi de télé-information tout en envoyant ces données en wifi… ?
Concernant ESPhome on peut mettre l’ESP facilement en deep sleep et le réveiller de temps en temps. Je t’invites vraiment à essayer à l’occaz, ça évite de longues nuit à coder des firmwares dédiés aux sensors.
@dckiller oui oui c’est vrai on digresse un peu 
je n’ai pas de problème non plus pour alimenter mon ESP8266 mais le sujet est intéressant et pourrait rendre service à pas mal de monde si la problématique trouvait une issue
Concernant la nouvelle version de la téléinfo sous ESPhome tu ne devrais pas voir de grosse différence si ce n’est qu’à mon avis c’est codé beaucoup plus proprement
@Schmurtz, ta tension de 13v/14v est une tension à vide en sortie de ton pont redresseur, en charge c’est plutôt 6v.
La consommation d’un arduino pro mini comme dans mon montage consomme environ 10mA, le redresseur LDO vers les 4/5mA et les leds 5mA. Il reste 39-10-5-5=19mA pour alimenter la partie Wifi ou autre. Pour le wifi c’est pas possible car il faut avoir assez au minima 150mA. un module NRF est compatible mais en faible puissance car celui-ci consomme 10mA.
Pour mettre en ESP01, il faut passer par une réserve via un supercondensateur à l’image de la clé Atome ou mettre un accu. Pour que cela fonctionne il faut que le condo puisse alimenter l’ESP pendant la phase de lecture des 50 données venant du Linky (2/3 secondes) et ensuite alimenter le Wifi pendant 5 secondes je pense. Ce n’est pas infaisable mais Quid de la portée d’un ESP01 en wifi ?
Il est possible d’utiliser la clé Atome sur un Linky à 30 mètres de ta maison ? J’ai quelques doutes…
Salut,
J’en profite pour donner mon retour d’expérience.
Je suis parti du fameux montage de hallard.me que reprend @Schmurtz avec son custom component TIC pour ESPhome.
Premièrement j’ai passé une semaine à comprendre pourquoi mon montage ne fonctionnait pas à l’aide de multimètre et oscilloscope pour finalement m’apercevoir que sur les deux composants achetés sur Aliexpress (l’optocoupleur et le MOSFET), j’avais… deux mauvais composants ! Tout d’abord on ne m’a pas envoyé le bon modèle d’optocoupleur, mais c’est écrit dessus, puis j’ai reçu une contrefaçon de MOSFET ! Oui je savais pas que ça existait, il y a écrit le bon modèle dessus mais c’était un simple transistor bipolaire NPN… Donc faites-gaffe en commandant sur Aliexpress car on perd vite du temps !
Une fois mes nouveaux (bons) composants reçus, je suis parti tout d’abord sur le logiciel Wifinfo pour ESP8266 pour vérifier que je décodais bien les trames teleinfo sur une page web dédiée. Résultat : ça fonctionne mais de mon côté c’était pas super stable, j’ai l’impression que parfois ça rame, la page web ne se rafraichit plus.
Ensuite, j’allais utiliser le custom component TIC de @Schmurtz pour ESPhome mais en faisant un pull de la branche dev du github ESPhome j’ai vu par coïncidence que la teleinfo venait d’être ajoutée ! Voici la doc associée (qui a un bug dans l’exemple que je vais corriger, il faut remplacer tag par tag_name). Ainsi j’ai testé d’ajouter ce nouveau composant sur mon ESP8266. Mon premier essai est un échec : l’ESP8266 part en boot loop, même en ne déclarant que l’UART. Je vais donc voir l’exemple de yaml pour ESP8266 de @Schmurtz et comprends où ça coince : il faut désactiver les logs sur le port série ! Avec cette modification, je charge le logiciel en OTA sur l’ESP8266 et bingo ça fonctionne ! Home Assistant détecte bien mon ESP et ses 3 entités :
Je n’ai ajouté que les 3 paramètres de l’exemple mais le composant teleinfo ne limitant pas les étiquettes reçues, on peut ajouter toutes celles qu’on veut tant qu’elles existent.
Au final, si on a les bons composants et l’astuce de @Schmurtz c’est très facile (je pense que sur l’esp32 on a moins de soucis). Pour tester la fiabilité, j’ai laissé l’ESP8266 toute la nuit et au réveil il continuait à envoyer les infos, je vois juste dans la console ESPhome d’Home Assistant que la connexion se perd régulièrement quelques secondes, est-ce dû à ESPhome, à Home Assistant ou à l’ESP8266, je ne sais pas, mais si ça ne fait que teleinfo ça ne gène pas.
Voici ma conf ESPhome :
esphome:
name: teleinfo
platform: ESP8266
board: nodemcu
wifi:
ssid: "<SSID>"
password: "**********"
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Teleinfo Fallback Hotspot"
password: "*********"
captive_portal:
logger:
baud_rate: 0 # disable logging via UART, help to avoid numerous crash with ESP_LOGD
level: INFO # INFO for less log, put DEBUG to view all the linky's "étiquettes" received in the logs
esp8266_store_log_strings_in_flash: False # recommanded for ESP8266 https://esphome.io/components/sensor/custom.html
# Enable Home Assistant API
api:
password: "*********"
ota:
password: "**********"
uart:
id: uart_bus
rx_pin: GPIO13
baud_rate: 1200
parity: EVEN
data_bits: 7
sensor:
- platform: teleinfo
tags:
- tag_name: "HCHC"
sensor:
name: "hchc"
unit_of_measurement: "Wh"
icon: mdi:flash
- tag_name: "HCHP"
sensor:
name: "hchp"
unit_of_measurement: "Wh"
icon: mdi:flash
- tag_name: "PAPP"
sensor:
name: "papp"
unit_of_measurement: "VA"
icon: mdi:flash
update_interval: 10s
historical_mode: true
A noter que je n’ai pas mis de bit de stop contrairement à @Schmurtz.
J’en profite pour remercier toutes les personnes qui ont contribué à cette intégration, je n’ai fait qu’intégrer différents travaux et au final la solution est simple et fonctionnelle.
2 « J'aime »
@djtef Et tu ne racontes pas l’anecdote du facteur qui ta piqué 2 MOFSET ?
Merci bien pour ce retour d’expérience très riche
Effectivement, je peux ajouter que lorsque je me suis aperçu que je n’avais pas reçu le bon composant pour le MOSFET, @oncleben31 m’a gentiment proposé de m’en envoyer deux qu’il avait en stock par courrier pour gagner du temps. Je les reçois le lendemain, sauf que je m’aperçois que la lettre a un trou… et qu’elle ne contient plus les 2 MOSFET ! Après des mauvais optocoupleurs, des MOSFET contrefaits, voilà que je me les fais voler lors du 2e envoi… j’ai tendance à croire que le sort s’acharne sur moi Qui peut vouloir voler des MOSFET à 20 centimes ?? Mystère ! 
Ah top ce retour ! Ca faisait quelques jours que je devais justement installer la branche dev de ESPhome pour tester ce nouveau composant Merci du coup pour ce test !
L’auteur de ce nouveau composant m’a ouvert un ticket justement à ce sujet N’hésites pas à y poster tes retours notamment sur le port UART et les pertes de connexion (qui pour moi sont des crashs de l’ESP, tu peux ajouter l’uptime pour en avoir le coeur net). Voici un pti code sympa pour l’uptime :
text_sensor:
- platform: template
name: ${name} - Uptime
update_interval: 60s
icon: mdi:clock-start
lambda: |-
int seconds = (id(uptime_seconds).state);
int days = seconds / (24 * 3600);
seconds = seconds % (24 * 3600);
int hours = seconds / 3600;
seconds = seconds % 3600;
int minutes = seconds / 60;
seconds = seconds % 60;
if ( days ) {
return { (String(days) +"d " + String(hours) +"h " + String(minutes) +"m "+ String(seconds) +"s").c_str() };
} else if ( hours ) {
return { (String(hours) +"h " + String(minutes) +"m "+ String(seconds) +"s").c_str() };
} else if ( minutes ) {
return { (String(minutes) +"m "+ String(seconds) +"s").c_str() };
} else {
return { (String(seconds) +"s").c_str() };
}
Le composant natif ne va pas changer grand chose au quotidien si ce n’est qu’il va simplifier l’installation et le code qu’a écrit 0hax est super propre avec possibilité de déclarer les étiquettes dont on a besoin (plus flexible).
Ouiiii j’ai galéré avec ça également ! En effet ESPhome écrit un max de logs dans le port série et bien que l’on se serve d’un autre port pour le TIC celà semble poser problème. La partie UART de ESPhome n’est pas hyper précise sur ce point : si l’on déclare un nouveau port UART, est ce que l’écriture des logs restent sur le port par défaut ou est ce que ça passe dans le nouveau port déclaré ? Un simple test permettrait de répondre à la question mais je n’ai pas pris le temps de le faire. Ou bien il y’a un bug dans ESPhome à ce niveau. Ce qui est certain c’est que si on laisse les logs UART ça crash en effet.
Alors tant qu’on est sur ce sujet, juste pour info, Charles Hallard (que je remercie pour son énorme taf hyper quali sur le sujet) m’a partagé un code pour ESPhome hyper poussé. Ce n’est pas basé sur ESPhome mais c’est un peu le TIC via ESP8266 ultime. Le code se trouve là et un des rares screenshot ici . Globalement le forum de Charles regorge de codes et d’infos interessantes sur le sujet !
Sinon pour les fous de tasmota il y’a aussi ce code.
Pour la petite histoire des transports j’ai connu pire que 2 mosfet ! De mon coté un jour on m’a volé 100 boutons xiaomi 
Bref maintenant que l’on a mainte et mainte manières de récupérer les infos… Est ce que quelqu’un a déjà fait quelque chose de clean pour les afficher sur Home Assistant ?
J’aime beaucoup la présentation de cette custom card mais des regroupement par mois me paraissent pertinents.
Il faut reconnaitre que les graph de l’interface « equilibre » d’edf sont pas mal. La répartition heure creuse/heure plein par exemple c’est une bonne idée.
Peut-être que le plus simple est de s’inspirer de ce qu’a fait M4dm4rtig4n dans grafana ? … Je ne sais pas, je suis sur que ça existe déjà car certains mesurent également depuis belle lurette avec des SCT-013 ou des PZEM-004T et sont donc confrontés à de problématiques de présentation du même genre 
Par contre, question un peu annexe, comment font-il leur truc de répartition entre les différents appareils ?? Parceque faire la différence entre une télé et un cumulus c’est plutot simple vu la différence de courant utilisé mais entre un cumulus et un chauffage électrique, comment font-ils ?
@Schmurtz merci pour toutes ces infos.
Je viens d’ajouter un message à votre discussion sur le composant téléinfo esphome.
Bonne idée d’ajouter l’uptime, par contre je ne comprends pas dans le code comment la variable uptime_seconds est calculée 
Je suis d’accord que ça demande de se pencher sur l’histoire des logs qui font planter l’esp, ça sent le bug ESPhome je pense, parce que je ne vois pas de lien vu que ce sont deux broches différentes.
J’avais pas mal lu le forum de Charles Hallard, c’est une mine d’info sur la téléinfo. Justement je pensais devoir passer par du json ou MQTT, que certains commençaient à implémenter, pour communiquer avec Home Assistant. Mais heureusement vous êtes passés par là pour ajouter le composant dans ESPhome, ça simplifie grandement les choses. Sinon si on n’a pas de serveur central domotique, la solution libteleinfo est géniale, c’est un vrai centre de contrôle autonome !
Que comptais-tu faire avec 100 boutons Xiaomi ?! 
Pour la présentation des données, j’ai vu quelques exemples sympa sur Youtube, peut-être même de membres HACF. C’est sûr qu’avec Grafana on doit pouvoir faire tout ce qu’on veut, mais perso j’aimerai avoir une solution plus légère. J’ai vu qu’avec la dernière version d’Home Assistant on pouvait configurer facilement des grilles, pour l’instantané ça peut être pas mal. Ensuite ce qui est intéressant c’est la comparaison avec les jours, semaines et mois précédents. Le but c’est d’arriver à voir facilement si on peut optimiser et/ou économiser de l’énergie.
Pour ta dernière question, soit c’est du bluf, soit des du pifomètre, soit ils se basent sur l’échelon de consommation que t’as lors du passage aux heures creuses, en principe c’est le cumulus qui se met directement si t’as branché le contacteur sur HC/HP.
Nickel, j’ai lu ça, merci !
Ben en la déclarant 
…hum… (je l’avais un peu oubliée 
) . ça ira mieux avec ça :
- platform: uptime
id: uptime_seconds
name: "Uptime Sensor"
update_interval: 60s
unit_of_measurement: s
accuracy_decimals: 0
force_update: false
icon: mdi:timer
internal: True # Hide to HA
Yes, ça va être interessant d’en discuter avec 0hax voir ce qu’il en pense, il a probablement était confronté au problème à moins que sous ESP32 ça se passe mieux…
Un petit projet pour une école
J’essairai de regarder ça bientot, je propose que l’on se tienne au jus ici de nos trouvailles
J’ai activé le bouzin, je pourrai bientot me faire une idée une fois qu’EDF aura pompé assez d’infos pour représenter ma vie sur un graphique 
1 « J'aime »
J’ai plus qu’à commander le matériel pour qu’il arrive dès que le compteur sera monté.
L’avantage de cette solution est la consommation en direct ? Contrairement au fonctionnement d’enedis qui te permet seulement de récupérer tes consommation de la veille.
@McFly, tu aurais des liens affiliés pour :
- un ESP32
- un FTDI
Avec grand plaisir @Sylvain_G merci d’avance
ESP32 : recherche
Amazon aussi ? sachant que c’est beaucoup plus cher.
ESP32 : recherche
https://www.amazon.fr/s?k=esp32&__mk_fr_FR=ÅMÅŽÕÑ&ref=nb_sb_noss_1?tag=hacf0d-21
FTDI : recherche
https://www.amazon.fr/s?k=ftdi&__mk_fr_FR=ÅMÅŽÕÑ&ref=nav_signin?tag=hacf0d-21
1 « J'aime »
A moitié hors sujet car on parle de téléinfo via wifi mais quand même à surveiller !
L’auteur de la zigate s’attaque au linky via le protocole zigbee. L’idée est cool car les puces zigbee consommant moins le module pourra être auto-alimenté.
Franchement c’était un vrai plaisir de lire ses articles sur la zigate car il y’avait beaucoup de transparence dans cette aventure racontée point par point.
Hate de lire la suite à propos de ce nouveau sensor !
@Schmurtz, est-ce que tu aurais :
- un tuto où je pourrais retrouver un fichier gerber pour la carte additionnelle à un ESP32 pour le faire fabriquer/monter par jlcpcb.com (sachant que je suis très mauvais « soudeur », j’ai déjà grillé un RPi à cause d’une carte additionnelle que j’avais fait)
- un tuto pour flasher l’ESP32 avec le code qui va bien pour récupérer sur ESPHome les informations
- un tuto pour intégrer toutes ces informations à une superbe carte
En fait je voudrais écrire un tuto de « bout en bout » pour un nouveau comme moi pour intégrer le suivi d’un compteur Linky sur une belle carte HA. Sous le format de ce tuto qui est d’ailleurs très clair. Il y a meêm un principe de version.
Avec plaisir mais comment doit-on procéder ?
via une pull request du fork que j’aurai fait auparavant ou directement en ayant les droits ?
C’est pour rester dans le standard
Faut faire une PR à la suite du fork
Merci @Sylvain_G . il y a quelques commentaires à prendre en compte avant de merge.