Teleinfo is officially supported in esphome dev branch now

[0hax]

Hello,

Small message to let you know that teleinformation is officially supported in esphome dev branch now.
esphome/esphome#1108
So you should no more need to create your custom component.

[schmurtzm]

That's a really good news ! I will try that soon !

[schmurtzm]

Hello, j'ai zieuté un peu le code, ça a l'air top.
SI je peux donner mon avis, quitte à faire un composant officiel je trouve dommage que tu ne remontes pas un maximum d'étiquettes.
Bon c'est vrai qu'avec HCHC,HCHP et PAPP on a l'essentiel de ce qui nous interesse... Mais bon tant qu'on y est 😄

Je pense l'exemple devrait fournir toutes les étiquettes dispo en mode historique, ensuite l'utilisateur pioche ce qui l’intéresse dans l'exemple présent dans la doc ;)

Qu'est ce que tu en penses ?

[schmurtzm]

Moi j'ai ça par exemple... Et encore je ne remonte pas toutes les étiquettes à dispo.

[0hax]

Hello,
C'est pas forcément clair depuis le code mais tu peux récupérer n'importe quel tag selon ce que tu spécifies dans le yaml.
C'est précisé dans la doc ici: esphome/esphome-docs@ff31428
Par exemple, si tu veux l'intensité instantanée IINST en plus de HCHP HCHC et PAPP:

    sensor:
      - platform: teleinfo
        tags:
         - name: "HCHC"
           sensor:
            name: "hchc"
            unit_of_measurement: "Wh"
            icon: mdi:flash
         - name: "HCHP"
           sensor:
            name: "hchp"
            unit_of_measurement: "Wh"
            icon: mdi:flash
         - name: "PAPP"
           sensor:
            name: "papp"
            unit_of_measurement: "VA"
            icon: mdi:flash
         - name: "IINST"
           sensor:
            name: "Intensité"
            unit_of_measurement: "A"
            icon: mdi:flash
        update_interval: 60s
        historical_mode: true

En éspérant que ce soit plus clair !

[schmurtzm]

ah génial ! Merci pour l'exemple ! Je crois que j'ai lu la doc à une heure trop tardive 😅
Je vais tester ça en ajoutant quelques étiquettes et je te fais un retour d'expérience.

[djtef]

Salut @0hax,
J'ai un peu discuté avec @schmurtzm au sujet de la teleinfo via ESPhome sur le forum hacf . Suite à son conseil je te contacte pour que tu voies mon retour d'expérience de mon test de ton nouveau composant teleinfo.
Pour info je me suis permis d'ajouter quelques corrections sur la doc ici.
Pour que ça fonctionne, @schmurtzm a vu qu'il fallait désactiver les logs sur l'UART, ce qui nous semble bizarre vu qu'on n'est pas sur la même broche RX.... Moi j'avais quelques soucis de stabilité, ça semble beaucoup mieux en fixant une adresse IP statique. Mais comme me le conseille @schmurtzm je vais ajouter l'info uptime pour vérifier.
La question que je me pose à présent, c'est si je veux me servir de ces infos pour faire du délestage, est-ce que je peux faire envoyer une alerte instantanément à ESPhome même si je laisse le paramètre update_interval à 60s par exemple ? Ne peut-on pas rafraichir la donnée à permanence sur l'ESP mais ne la publier sur HA que toutes les 60s ?
En tout cas merci pour vos dev, je trouvais dommage qu'il n'y ait rien pour HA alors que Jeedom et Domoticz étaient bien couverts !

[lolorc]

je pense qu'il faudrait vérifier le checksum aussi, j'ai de nombreuses erreurs, ex

Nov 25 15:34:45 esp32_03/debug [D][tic:097]: tic BASE : 01758^G&^Wwg&538328
Nov 25 15:34:33 esp32_03/debug [V][mqtt:372]: Publish(topic='esp32_03/sensor/index/state' payload='17589' retain=1)                                                                                               │

aussi index un mot clef qui pose problème à influxdb on dirait.

je vais regarder si je peux implémenter cela, en plus du changement de l'id de BASE je vais le laisser en W/h

edit: done, j'attends un peu d'avoir une erreur pour voir si mon nouveau sensor_ERRORS remonte correctement puis je publierai mes changement

[lolorc]

implémenté la : https://github.com/lolorc/Teleinfo-TIC-with-ESPhome/tree/checksum

[0hax]

Salut @0hax,
J'ai un peu discuté avec @schmurtzm au sujet de la teleinfo via ESPhome sur le forum hacf . Suite à son conseil je te contacte pour que tu voies mon retour d'expérience de mon test de ton nouveau composant teleinfo.
Pour info je me suis permis d'ajouter quelques corrections sur la doc ici.
Pour que ça fonctionne, @schmurtzm a vu qu'il fallait désactiver les logs sur l'UART, ce qui nous semble bizarre vu qu'on n'est pas sur la même broche RX.... Moi j'avais quelques soucis de stabilité, ça semble beaucoup mieux en fixant une adresse IP statique. Mais comme me le conseille @schmurtzm je vais ajouter l'info uptime pour vérifier.

Salut @djtef ,
Merci pour ton retour et ta contribution que je vais essayer de revoir bientôt.
Pour le problème d'uart, sur quelle broche as tu relié la téléinfo ?
De mon côté j'utilise l'UART hardware donc je l'ai branché sur la broche RX (celle à côté du VCC) et j'ai donc désactivé l'uart_logger de esphome pour qu'il n y ait pas de conflits entre les 2.
Je ne recommande pas l'utilisation du SW Serial qui est très buggué et peut rendre l'esp instable.

Voici un exemple de ma configuration qui tourne depuis quelques mois sur 2 sonoff basic (compteur production et consomation)

esphome:
  name: teleinfo_pompe
  platform: ESP8266
  board: esp8285
  arduino_version: 2.4.2

wifi:
  ssid: ""
  password: ""

logger:
  baud_rate: 0

mqtt:
  broker: mybroker
  log_topic: log

uart:
  id: uart_bus
  rx_pin: GPIO3
  tx_pin: GPIO1
  baud_rate: 1200
  parity: EVEN
  data_bits: 7

sensor:
  - platform: teleinfo
    tags:
     - name: "HCHC"
       sensor:
        name: "hchc"
        unit_of_measurement: "Wh"
        icon: mdi:flash
     - name: "HCHP"
       sensor:
        name: "hchp"
        unit_of_measurement: "Wh"
        icon: mdi:flash
     - name: "PAPP"
       sensor:
        name: "papp"
        unit_of_measurement: "VA"
        icon: mdi:flash
    update_interval: 60s
    historical_mode: true`

La question que je me pose à présent, c'est si je veux me servir de ces infos pour faire du délestage, est-ce que je peux faire envoyer une alerte instantanément à ESPhome même si je laisse le paramètre update_interval à 60s par exemple ? Ne peut-on pas rafraichir la donnée à permanence sur l'ESP mais ne la publier sur HA que toutes les 60s ?
En tout cas merci pour vos dev, je trouvais dommage qu'il n'y ait rien pour HA alors que Jeedom et Domoticz étaient bien couverts !

Tu pourrais rafraichir plus souvent en modifant le code mais j'ai pas trop compris ce que tu veux dire par 'délestage' ?

Je vais essayer de faire un post sur mon site pour expliquer le montage avec un sonoff basic et comment traiter les données côté home assistant et avoir de beaux graphiques sur Grafana.

[0hax]

implémenté la : https://github.com/lolorc/Teleinfo-TIC-with-ESPhome/tree/checksum

Salut @lolorc
Je pense que cette contribution est pour le projet initial. Tu devrais peut etre en parler dans #1

[lolorc]

@0hax oh oui pardon, j'ai pas fait attention :-)
du coup j'suis à l'ouest ;-)
j'utilise aussi esphome dev que je n'ai pas mis à jour depuis quelques semaines, peux tu rajouter un compteur de bad crc ou tu préfères que je fasse un PR pour cela ?

[djtef]

Salut @0hax

Pour le problème d'uart, sur quelle broche as tu relié la téléinfo ?

J'ai utilisé GPIO13 qui est RX2 du 2e UART vu que le premier est utilisé pour la programmation et les logs. D'après ce que j'ai compris on peut en utiliser qu'un en même temps et il faut "swapper" les pins (Serial.swap()) pour changer d'UART dynamiquement.

De mon côté j'utilise l'UART hardware donc je l'ai branché sur la broche RX (celle à côté du VCC) et j'ai donc désactivé l'uart_logger de esphome pour qu'il n y ait pas de conflits entre les 2.
Je ne recommande pas l'utilisation du SW Serial qui est très buggué et peut rendre l'esp instable.

Du coup t'as désactivé les logs comme @schmurtzm et moi. Il n'y a donc pas moyen d'avoir les deux.

Tu pourrais rafraichir plus souvent en modifant le code mais j'ai pas trop compris ce que tu veux dire par 'délestage' ?

Le délestage permet d'avoir un abonnement élec sous-dimensionné par rapport aux pics de charge qu'on peut avoir et donc prioriser certains appareils le temps de ces pics. Par exemple j'ai le chauffage et le four, puis j'utilise le fer à repasser, imaginons que ça me fait dépasser la conso autorisée, je peux automatiquement couper le chauffage pendant la demi-heure où je repasse en pilotant un contacteur. Mais pour ça il faut être rapide, il faut couper avant que ça disjoncte. Le délestage n'est pas nouveau, ça existe en mécanique directement dans le tableau sur rail Din, là ça permet de le rendre plus intelligent.
Du coup je me demande quelle est la fréquence max que l'ESP8266 supporte. Je me disais qu'on pourrait différencier la fréquence d'acquisition sur l'UART et la publication sur l'api. Ça permettrait d'avoir une logique interne à l'ESP très rapide mais après d'envoyer chaque minute ça peut suffire pour les stats.

[0hax]

@0hax oh oui pardon, j'ai pas fait attention :-)
du coup j'suis à l'ouest ;-)
j'utilise aussi esphome dev que je n'ai pas mis à jour depuis quelques semaines, peux tu rajouter un compteur de bad crc ou tu préfères que je fasse un PR pour cela ?

Ah oui bonne idée, toute contribution est la bienvenue, envoi une PR quand tu veux 👍

[schmurtzm]

De mon côté j'utilise l'UART hardware donc je l'ai branché sur la broche RX (celle à côté du VCC) et j'ai donc désactivé l'uart_logger de esphome pour qu'il n y ait pas de conflits entre les 2.
Je ne recommande pas l'utilisation du SW Serial qui est très buggué et peut rendre l'esp instable.

Il faudrait qu'on le spécifie explicitement dans la doc (ça évitera que tout le monde test les ports SW ou laisse activé le serial output pour finalement faire le même constat d'instabilité après une longue analyse).
Notamment en ce qui concerne l'ESP8266 : conseiller d'activer l'écoute uniquement sur les ports hardware et de désactiver systématiquement uart_logger.

Cependant, de ce que je comprends l'ESP8266 a quand même 2 port hardware dont un qui est en TX uniquement : UART0 may use either tx_pin: GPIO1 and rx_pin: GPIO3, or tx_pin: GPIO15 and rx_pin: GPIO13. UART1 must use tx_pin: GPIO2
Peut-être que l'on pourrait conseiller d'utiliser l'UART0 pour la TIC et l'UART1 pour le log (qui est quand même bien pratique pour debugger) ?
A tester !

Voici un exemple de ma configuration qui tourne depuis quelques mois sur 2 sonoff basic (compteur production et consomation)

Merci ;)

Tu pourrais rafraichir plus souvent en modifant le code mais j'ai pas trop compris ce que tu veux dire par 'délestage' ?

Je vais essayer de faire un post sur mon site pour expliquer le montage avec un sonoff basic et comment traiter les données côté home assistant et avoir de beaux graphiques sur Grafana.

Canon, envoies nous l'adresse de ton site au passage 😃
Ce serait cool qu'on arrive à faire une custom card (dans ce style) qui agrège quelques données sans forcément utiliser graphana (je ne sais pas dans quelle mesure c'est possible / difficile).

[0hax]

J'ai utilisé GPIO13 qui est RX2 du 2e UART vu que le premier est utilisé pour la programmation et les logs. D'après ce que j'ai compris on peut en utiliser qu'un en même temps et il faut "swapper" les pins (Serial.swap()) pour changer d'UART dynamiquement.

Si tu utilises le GPIO13, tu n'utilises pas le bloc hardware de l'esp8266 et une uart logicielle qui est buggé sur esphome.
Donc je te recommande de passer sur GPIO03.

Du coup t'as désactivé les logs comme @schmurtzm et moi. Il n'y a donc pas moyen d'avoir les deux.

Par contre, en utilisant GPIO13, tu devrais pouvoir garder le logger.
Je ne me souviens pas avoir vu de boot loops avec mes tests sur une uart logicielle mais je pourrais re-vérifier à l'occasion.

Tu pourrais rafraichir plus souvent en modifant le code mais j'ai pas trop compris ce que tu veux dire par 'délestage' ?

Le délestage permet d'avoir un abonnement élec sous-dimensionné par rapport aux pics de charge qu'on peut avoir et donc prioriser certains appareils le temps de ces pics. Par exemple j'ai le chauffage et le four, puis j'utilise le fer à repasser, imaginons que ça me fait dépasser la conso autorisée, je peux automatiquement couper le chauffage pendant la demi-heure où je repasse en pilotant un contacteur. Mais pour ça il faut être rapide, il faut couper avant que ça disjoncte. Le délestage n'est pas nouveau, ça existe en mécanique directement dans le tableau sur rail Din, là ça permet de le rendre plus intelligent.
Du coup je me demande quelle est la fréquence max que l'ESP8266 supporte. Je me disais qu'on pourrait différencier la fréquence d'acquisition sur l'UART et la publication sur l'api. Ça permettrait d'avoir une logique interne à l'ESP très rapide mais après d'envoyer chaque minute ça peut suffire pour les stats.

Merci pour l'explication.
Tu peux essayer de rafraichir toutes les 2 secondes, ca doit marcher. Le compteur envoi les infos à un certain intervalle aussi, tu pourras pas aller plus vite que çà.

[0hax]

Il faudrait qu'on le spécifie explicitement dans la doc (ça évitera que tout le monde test les ports SW ou laisse activé le serial output pour finalement faire le même constat d'instabilité après une longue analyse).
Notamment en ce qui concerne l'ESP8266 : conseiller d'activer l'écoute uniquement sur les ports hardware et de désactiver systématiquement uart_logger.

Bonne idée, tu peux faire une PR si tu veux, sinon je le ferais plus tard.

Cependant, de ce que je comprends l'ESP8266 a quand même 2 port hardware dont un qui est en TX uniquement : UART0 may use either tx_pin: GPIO1 and rx_pin: GPIO3, or tx_pin: GPIO15 and rx_pin: GPIO13. UART1 must use tx_pin: GPIO2
Peut-être que l'on pourrait conseiller d'utiliser l'UART0 pour la TIC et l'UART1 pour le log (qui est quand même bien pratique pour debugger) ?
A tester !

Oui tu as raison. J'ai fait le dévelopement il y a quelques mois donc je me souviens plus trop mais j'utilisais surement le TX de l'UART2 pour debugger ou les logs sur MQTT.

Canon, envoies nous l'adresse de ton site au passage smiley

J'ai pas de site pour le moment, mais j'essaye d'en faire un ce week end et je partagerais l'adresse.

Ce serait cool qu'on arrive à faire une custom card (dans ce style) qui agrège quelques données sans forcément utiliser graphana (je ne sais pas dans quelle mesure c'est possible / difficile).

Ah en effet c'est pas mal, je regarderais à l'occasion.

[schmurtzm]

Si tu utilises le GPIO13, tu n'utilises pas le bloc hardware de l'esp8266 et une uart logicielle qui est buggé sur esphome.
Donc je te recommande de passer sur GPIO03.

A priori si : sur l'ESP8266 on a 2 port hardware (dont un uniquement en TX) :

UART0 :

• tx_pin: GPIO1
• rx_pin: GPIO3

**ou (uart0 swap) **

• tx_pin: GPIO15
• rx_pin: GPIO13

UART1

tx_pin: GPIO2

Du coup il faudrait essayer de passer le log sur l'UART1 via le paramètre hardware_uart .
Évidemment tout ceci concerne surtout l'ESP8266 car on a plus d'UART hardware avec l'ESP32.

[schmurtzm]

Bonne idée, tu peux faire une PR si tu veux, sinon je le ferais plus tard.

Je vais tester ça. Une fois que je saurai si ça fonctionne bien ou pas je te ferai une PR

J'ai pas de site pour le moment, mais j'essaye d'en faire un ce week end et je partagerais l'adresse.

Si tu as la fleme de faire un site et que tu veux quand même de la visibilité, je t'invite à poster sur le forum de hacf , M4dm4rtig4n vient d'y poster une API pour remonter les infos d'Enedis, c'est bien on resterait dans le thème ;)

Ah en effet c'est pas mal, je regarderais à l'occasion.

Ahah on te donne du pain sur la planche 😄 ! Je ne suis pas le plus compétent pour faire des custom cards mais certains de la communauté hacf sont spécialisés dans le dev... Si tu as besoin d'un coup de main, n'hésites pas !

[djtef]

@schmurtzm @0hax dans mon PR j'ai ajouté un warning dans la doc pour désactiver les logs sur l'uart

[lolorc]

@0hax oh oui pardon, j'ai pas fait attention :-)
du coup j'suis à l'ouest ;-)
j'utilise aussi esphome dev que je n'ai pas mis à jour depuis quelques semaines, peux tu rajouter un compteur de bad crc ou tu préfères que je fasse un PR pour cela ?

Ah oui bonne idée, toute contribution est la bienvenue, envoi une PR quand tu veux

me suis pas trop embêté :-)
https://github.com/lolorc/esphome/tree/teleinfo_crc_counter

[0hax]

@0hax oh oui pardon, j'ai pas fait attention :-)
du coup j'suis à l'ouest ;-)
j'utilise aussi esphome dev que je n'ai pas mis à jour depuis quelques semaines, peux tu rajouter un compteur de bad crc ou tu préfères que je fasse un PR pour cela ?

Ah oui bonne idée, toute contribution est la bienvenue, envoi une PR quand tu veux

me suis pas trop embêté :-)
https://github.com/lolorc/esphome/tree/teleinfo_crc_counter

Merci!
Hésite pas à faire une pull request sur le github de esphome pour qu'une review soit faite.

Concernant mon site web, j'ai presque terminé, il me reste plus qu'à ajouter la possibilité de faire des commentaires sur les posts du blog.
J'ai déjà écrit comment utiliser esphome sur le sonoff basic pour récupérer la téléinformation.
Une preview est dispo ici:
https://0hax.github.io/

[schmurtzm]

Hello, je suis assez surpris de voir la nouvelle release de ESPhome soit dispo sans prendre en compte les modifs de @djtef ...
C'est dommage car l'exemple officiel fourni contient des erreurs à corriger si on veut compiler... Ce sont des petites pétouilles mais c'est quand même dommage pour une release officielle surtout sachant que ça avait été corrigé (notamment les balises "name" au lieu de "tag_name") :/
De même le fait de ne pas conseiller de désactiver les logs uart risque de faire planter tous ceux qui parviennent à faire à modifier l'exemple de la doc...
@djtef j'ai vu ta PR pour le MCP23008 mais pas pour la téléinfo, c'est peut-être moi qui ne maitrise pas assez github ou bien un oubli ? ;)

[schmurtzm]

@djtef , je vais faire une PR prenant en compte test modifs.

Edit : Done 👍
esphome/esphome-docs#998

L'enfer ce truc "reStructuredText" pour éditer la doc... je n'ai pas aimé du tout ! 😅 Franchement il faut être motivé pour modifier leur doc !

[0hax]

Ah en effet c'est dommage qu'il n'est pas incorporé mes derniers changements dans la release.
Je viens de voir çà :(
J'avais mis à jour la documentation et le code pour gérer les étiquettes sans valeurs.
Je vais voir quand est ce qu'ils pensent le merger.

[schmurtzm]

Je cherchais quelque chose de la part de djtef du coup j'avais pas vu ta PR @0hax .
J'ai enfin pris le temps de faire quelques tests. D'abord je tiens à dire que c'est du super boulot, merci pour ton partage !
Comme sur ma version, je confirme cependant les crashs avec les histoires d'uart donc c'est important que ce soit stipulé dans la doc.
Une fois qu'ils auront accepté les PR sur le sujet je modifierai mon repo pour préciser qu'il est obsolète.
Ils n'ont pas l'air super réactifs sur les PR, espérons que ce soit corrigé bientot :p

[djtef]

Hello, je suis assez surpris de voir la nouvelle release de ESPhome soit dispo sans prendre en compte les modifs de @djtef ...
C'est dommage car l'exemple officiel fourni contient des erreurs à corriger si on veut compiler... Ce sont des petites pétouilles mais c'est quand même dommage pour une release officielle surtout sachant que ça avait été corrigé (notamment les balises "name" au lieu de "tag_name") :/
De même le fait de ne pas conseiller de désactiver les logs uart risque de faire planter tous ceux qui parviennent à faire à modifier l'exemple de la doc...
@djtef j'ai vu ta PR pour le MCP23008 mais pas pour la téléinfo, c'est peut-être moi qui ne maitrise pas assez github ou bien un oubli ? ;)

Salut,

Pourtant je suis persuadé d'avoir corrigé la doc dans une PR .
Bizarre que ça ne soit pas pris en compte, j'ai peut-être mal fait la PR ?
Dommage qu'il n'aient pas mergé l'évolution pour avoir recevoir les chaînes de caractères, c'est utile de recevoir quand on passe de HC à HP.

[ysard]

@djtef, @0hax, @schmurtzm : Merci pour le temps investi sur ce projet.
Les PR dont vous parlez sur le dépôt esphome-docs ont été abandonnées par le bot faute d'activité pendant plus de 6 mois (statut Closed au lieu de Merged).
Personne en charge du dépôt n'est venu les vérifier, probablement plus par manque de temps que par manque d'intérêt.
Preuve que le code prime trop souvent sur la documentation :p
Toutefois de récentes PR ont été acceptées sur ce dépôt, vous avez donc dû tomber sur une mauvaise période.
Il vous faut persévérer en les rouvrant si possible, sinon il faudra contacter le mainteneur.

PS: La modification concernant la vérification du checksum, servant à rejeter les trames invalides me semble aussi très importante pour une inclusion dans une nouvelle PR.