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 çà.