Home Assistant, ESP & Téléinfo

On a vu précédemment qu'il était possible de récupérer la consommation électrique via le site Enedis, mais que c'était compliqué et lié au compteur Linky. On va explorer ici une méthode pour récupérer ces informations, plus complètes, directement sur le compteur, avec pour avantage que ça fonctionne également sur les anciens compteurs.

Je n'ai pas écrit cet article et encore moins réalisé ce montage (pour l'instant). Mais la nuit, on discute au sein d'une groupe Telegram des plus confidentiels (sur invitation et parrainage s'il vous plait) et c'est Mathieu (@Bibinsa) qui a réalisé ce montage et le code qui va avec. Face à la demande je lui ai donc demandé de me faire un récap et il m'a envoyé un fichier texte dans la plus pure tradition des codeurs. Je vais donc faire le secrétaire.

L'objectif ici est de récupérer les informations du compteur électrique.

  • compteurs à informations numériques (testé sur les compteurs pré-Linky mais devrait fonctionner aussi avec Linky)
    information Téléinfo TIC diffusées sur les afficheurs
  • Dans les installations "modernes", le compteur se situe dans le bâtiment (maison, ...) et un report Teleinfo est positionné sur le domaine public (rue, ...).

Cela permet aux agents (ENEDIS/Régie locale/Sous-traitant/...) de récupérer l'information sans demander l'accès au compteur dans la maison. Linky et son infrastructure de téléreport déployée en mode "cloud" devrait à terme changer ce mode de fonctionnement. Pour autant, les compteurs Linky sont toujours munis de la sortie TIC.

Pour les spécifications techniques, Google est votre ami :

Ces compteurs sont donc munis d'un bornier avec les indications I1 et I2. Ce bornier n'est pas protégé par un scellé et est donc accessible sans sortir du cadre contractuel. Plusieurs solutions de récupération de l'information Teleinfo sont disponibles, Google est à nouveau votre ami. Nous allons ici voir une solution :

  • économe
  • pas si compliquée à mettre en œuvre pour qui connait un peu les différents éléments mis en place
  • ouverte (open source)
  • utilisant des protocoles de communication orientés domotiques

Le matériel

L'idée ici est de ne pas utiliser un système complexe (ordinateur Linux/Windows/...) pour récupérer simplement une information texte. Dans le monde de l'IoT, des chipsets très pratiques inondent nos équipements WiFi : les ESP8266 et dérivés. N'importe quel module basé sur un ESP82xx convient, pour peu que celui-ci dispose d'un GPIO RX accessible facilement. Donc des Sonoff, des Wemos, ...

Pour ce besoin spécifique, un Wemos D1 mini est le candidat idéal :

  • petit (pourra s'intégrer dans le compartiment du bas sur les compteur classiques)
  • bien pratique car muni d'une port micro-USB pour alimentation et pour le "flash"

Ce module servira d'intelligence, c'est lui qui fera tourner le petit système d'exploitation qui récupèrera les infos et les transmettra. A ce module, il faut ajouter un module TiC de type Serial qui se connecte aux bornes I1/I2 et permet la conversion du signal au format série. De la même manière, de nombreux montages sont disponibles sur Internet. Qu'on peut se faire soi-même ou commander.

Un français (forcément... on est un peu les seuls à avoir ce système... Minitel, TousAntiCovid toussa toussa) "Charles Halard" propose des modules tout prêts appelés PitInfo. Plusieurs shield disponibles dont le PitInfo light qui convient très bien. Ce module est compatible physiquement avec les Raspberry Pi (Zero, Zero W) mais ces ordinateurs sont bien trop puissant pour notre besoin. je vous conseille de commander ce module avec les connecteurs pré-soudés, ce n'est pas l'écart de prix qui va changer grand chose...

Nous allons donc nous servir de la capacité de l'ESP8266 à se connecter à n'importe quel shield. Et côté câblage ça donne :

  1. PitInfo TiC vers les bornes I2/I2
  2. Wemos D1 3,3V vers PitInfo Vcc
  3. Wemos GND vers PitInfo GND
  4. PitInfo Tx vers Wemos D1 Rx pour la communication et c'est tout

On n'oublie pas d'alimenter le Wemos en USB bien sûr. Le tout fonctionne donc en 3,3V et est alimenté par un simple câble micro-USB (5V). Il est également possible de s'alimenter sur la sortie idoine low voltage directement sur le compteur, mais dans ce cas cela nécessitera un convertisseur. A noter que si le compteur est situé en dehors du domicile, il sera souvent possible d'utiliser l'ancien câble servant au HP/HC pour y faire transiter les information série (les commandes HP/HC pouvant avantageusement être gérées par Home Assistant).

Mais avant de câbler tout ça, on va trouver un Firmware à mettre sur le Wemos D1 mini. On débranche PitInfo du Wemos... on va avoir besoin de libérer le port série.

Le firmware

Je suis un grand fan de Tasmota (ntlr : tout mon monde le sait), l'OS open source initialement inventé par Theo Arends pour piloter les modules chinois SonOff. Ce firmware alternatif est rapidement devenu compatible avec tous les ESP82xx (et bientôt les ESP32). On ne va pas parler ici de Tasmota, mais de comment récupérer la Teleinfo avec Tasmota.

Depuis la version 8.4, Tasmota embarque de quoi interpréter les infos Teleinfo. Et c'est grace en partie, au développeur de PitInfo. Seul bémol, les binaires Tasmota précompilés n'embarquent pas le code Teleinfo. Il faut donc le compiler soi-même... enfin presque. Une plate-forme de développement online, qui fonctionne avec un compte github, permet de compiler très simplement et sans compétence particulière un firmware Tasmota avec des options particulière. Cette plate-forme c'est GitPod. On se loggue sur github, on donne les droits à Gitpod. La doc Tasmota expique tout en détail et deux options sont possibles :

  1. - firmware stable
  2. - firmware dévellopement

Une dernière option, encore plus simple est disponible avec gitpod : tasmocompiler. C'est une interface web qui permet en quelques clic de compiler son firmware. Nous allons utiliser celle-ci. On charge l'URL dans un navigateur et on va prendre un café (c'est un peu long... ça compile au premier démarrage). Ensuite on check les autorisations de popup aussi, TasmoCompiler va lancer un popup avec l'interface web. Une fois le café ingurgité on est en face de l'interface web de Tasmocompiler en 5 étapes :

  1. on clic sur Download Source Code + Next
  2. La configuration WiFi : on peut passer cette étape si on maitrise l'onboarding Tasmota WiFi sinon c'est ici qu'on peut préconfigurer le SSID+Password (+ conf IP statique si besoin... pas conseillé !!!)
  3. Select Features : on ne va pas se mentir... Teleinfo n'est pas dans les features les plus réclamées par la communauté. Nous n'avons donc pas notre petite case à cocher ici.
    • Laisser les features pré remplies
    • Sélectionner des features supplémentaires si besoin (sensors T° ?)
  4. Custom parameters : c'est la partie qui nous intéresse, on ajoute :
     #ifndef USE_TELEINFO
     #define USE_TELEINFO
     #endif
  5. Select version and compile
    • sécurité : version prod (9.1.0 à la date de cet article)
    • core : 2.7.4
    • language : english - french ?
    • board : on peut spécifier Wemos D1 mini
    • speed : 80 MHz c'est largement suffisant

Compile ! (et second café... ). On récupère le binaire (firmware.bin) et c'est presque gagné. Il nous reste à uploader Tasmota sur le Wemos. Le Wemos D1 mini a de grands avantages :

  • un port micro-USB qui permet de communiquer avec lui
  • le mode flash par défaut, aucune manipulation

On va utiliser ici l'outil qui a grandement simplifié le flash des modules ESP82xx : Tasmotizer, Sous Windows, Mac ou Linux, une fois l'outil installé proprement :

  • Brancher le Wemos à votre ordinateur
  • Lancer tasmotizer
  • Sélectionner le bon port COM
  • Select Image : votre firmware.bin précédemment compilé
  • Erase flash before flashing (c'est toujours plus propre)
  • Tasmotize !!!

Quelques secondes plus tard, votre module est prêt. On peut procéder au câblage comme indiqué au début de l'article. Une fois le module démarré, et selon votre configuation WiFi dans tasmocompiler :

  • il diffuse un hotspot pour l'onboarding (se connecter au SSID diffusé, portail captif qui permet de configurer les paramètres wifi du module)
  • il est accroché au SSID préconfiguré dans tasmocompiler

On peut se connecter à l'interface web de celui-ci pour effectuer sa configuration Tasmota :

La première étape de configuration est la déclaration du template. Un template c'est une sorte de préconfiguration du module. C'est ici qu'on spécifie le type de module utilisé (Teleinfo) et la réception des infos sur le connecteur Rx du Wemos. Le plus simple ici est d'aller sur la Console web et entrer les commandes :

  • Template {"NAME":"Wemos PitInfo","GPIO":[255,255,255,210,255,255,255,255,255,255,255,255,255],"FLAG":15,"BASE":18}
  • module 0

Le module redémarre. Si tout est bien connecté, vous devriez voir les informations Teleinfo sur la page web principale de Tasmota. Par défaut, le module utilise 1200 bps pour le port série. C'est la vitesse du port Teleinfo des compteurs classiques. Les compteurs Linky fonctionnent en 9600 bps, il faut donc modifier la vitesse en mode console SetOption102 1 et là ça devrait fonctionner pour les compteurs Linky, C'est pas mal mais ce n'est pas l'objectif.

Tasmota est surtout connu pour son support MQTT. On peut le configurer et récupérer toutes les informations via ce protocole. On va supposer ici que vous connaissez MQTT et que vous avez un broker de configuré. Dans Tasmota nous allons devoir entrer les informations suivantes (dans l'interface web de configuration ou sur la page console qui permet d'entrer des commandes) :

  • broker : addresse IP
  • topic : le topic de base du module (exemple ici : mon_wemos_teleinfo)
  • fulltopic : l'arboresence complète avec les variables
       exemple ici : maison/tasmota/%topic%/%prefix%/

Le module redémarre et est désormais accroché en MQTT à votre broker. Il peut se configurer, se piloter via ce protocole grâce auquel il envoie sa télémétrie. Nous allons maintenant régler cette dernière information. Deux possibilités :

  • Message MQTT à chaque modification sur le compteur 
  • Message MQTT à intervalle régulier (mode par defaut)

Pour ma part j'ai essayé la première option : c'est trop verbeux. Chaque seconde un message MQTT c'est trop souvent pour ce qu'on souhaite récupérer. Cependant, pour un monitoring très précis de la puissance (encore que... le Power n'est pas si précis que ça avec les moteurs, ...) le premier mode peut s'avérer utile. Pour l'activer on passe en mode console SetOption108 1. Si vous êtes resté sur le mode Télémétrie Energy (par défaut), vous allez avoir les informations dans le topic :

maison/tasmota/mon_wemos_teleinfo/tele/SENSOR

avec comme valeur quelque chose comme ça :

{"Time":"2020-11-18T12:16:28","ENERGY":{"TotalStartTime":"2020-10-18T00:00:00","Total":1861.951,"Yesterday":61.250,"Today":36.852,"Period":0,"Power":630,
"Current":3.000,"Load":6,"ADCO":"xxxxxxx","OPTARIF":"HC..","ISOUSC":45,"HCHC":62617552,
"HCHP":67058436,"PTEC":"HP..","IINST":3,"IMAX":52,"PAPP":630,"HHPHC":"A","MOTDETAT":0},"BME280":{"Temperature":9.8,"Humidity":53.6,"DewPoint":0.8,"Pressure":1009.0},"PressureUnit":"hPa",
"TempUnit":"C"}(spoiler : il y a un capteur de T°/Hum/Pression en + ici)

Pour ajuster la fréquence de report de la télémétrie, en console teleperiod <valeur en secondes>, pour garder le contenu en mémoire du broker (retain), toujours sous la console sensorretain 1.

Tasmota intègre nativement un suivi de consommation d'énergie. Le mode Teleinfo prend comme source le champ PAPP de Teleinfo et s'en sert de Wattmètre. Tasmota génère ensuite 3 compteurs :

  1. Daily (reset à 00h00)
  2. Yesterday (valeur de la veille)
  3. Total (valeur depuis la première initialisation)

On va s'en servir ensuite dans Home Assistant. il est possible de modifier ces valeurs, en particulier Total, pour s'en servir de compteur mensuel, annuel, ...

Configuration Home Assistant

C'est ici qu'on va voir toute la souplesse et la puissance de HA lorsqu'il récupère des informations de Tasmota. Nos objectif sont :

  • L'affichage des infos via des sensors dans Lovelace (Power, HC/HP, ...) et l'utilisation de certaines afin de conditionner des automations (HP/HC; EJP, ...)
  • Le suivi conso énergie via utility_meter: (autre article à venir...)

Toute la configuration se fait en mode sensor. On créée un sensor MQTT qui va se sourcer des informations JSON ENERGY généré par Tasmota toutes les x secondes (teleperiod), on créée également des sensor template qui vont parser les attributs du sensor MQTT pour extraire les infos souhaitées. Exemple :

Par exemple 

sensor:

# Teleinfo

#### Wemos D1 Mini + PitInfo : Teleinfo
#    - sensor = Energy Today (consommation journalière)
#    - attributs = tout le reste du JSON

- platform: mqtt
  name: 'Wemos PitInfo'
  state_topic: "maison/tasmota/mon_wemos_teleinfo/tele/SENSOR"
  value_template: "{{ (value_json['ENERGY'].Today) |float }}"
  unit_of_measurement: "kWh"
  device_class: energy
  availability_topic: "maison/tasmota/mon_wemos_teleinfo/tele/LWT"
  payload_available: "Online"
  payload_not_available: "Offline"
  json_attributes_topic: "maison/tasmota/mon_wemos_teleinfo/tele/SENSOR"
  qos: 1
#
#### Teleinfo attributes from Wemos_PitInfo
#
- platform: template
  sensors:
    #
    # Power
    teleinfo_puissance:
      value_template: '{{ state_attr("sensor.wemos_pitinfo","ENERGY").Power }}'
      unit_of_measurement: "W"
    #
    # EnergyHC
    teleinfo_energyhc:
      value_template: '{{ state_attr("sensor.wemos_pitinfo","ENERGY").HCHC }}'
      unit_of_measurement: "Wh"
    #
    # EnergyHP
    teleinfo_energyhp:
      value_template: '{{ state_attr("sensor.wemos_pitinfo","ENERGY").HCHP }}'
      unit_of_measurement: "Wh"
    #
    # Energy Total + attr HP/HC
    teleinfo_energy:
      value_template: '{{ state_attr("sensor.wemos_pitinfo","ENERGY").HCHC + state_attr("sensor.wemos_pitinfo","ENERGY").HCHP }}'
      unit_of_measurement: "Wh"
      attribute_templates:
        Index HP: >-
          {{ state_attr("sensor.wemos_pitinfo","ENERGY").HCHP }}
        Index HC: >-
          {{ state_attr("sensor.wemos_pitinfo","ENERGY").HCHC }}
    #
    # Energy yesterday
    teleinfo_energy_yesterday:
      value_template: '{{ ( state_attr("sensor.wemos_pitinfo","ENERGY").Yesterday *1000 ) |int }}'
      unit_of_measurement: "Wh"
    #
    # Energy total (year)
    teleinfo_energy_total:
      value_template: '{{ ( state_attr("sensor.wemos_pitinfo","ENERGY").Total *1000 ) |int }}'
      unit_of_measurement: "Wh"
    #
    # Periode Tarifaire
    teleinfo_periode_tarifaire:
      value_template: '{{ (state_attr("sensor.wemos_pitinfo","ENERGY").PTEC) |replace("..","") }}'

A partir de là vous voilà avec des sensors qui peuvent servir de sources de données pour faire du suivi de consommation (energy_meter) comme vu dans d'autres articles.

  • sensor.teleinfo_puissance : Puissance instantanée
  • sensor.teleinfo_energyhc : Index Heures Creuses (pour calcul coût)
  • sensor.teleinfo_energyhp : Index Heures Pleines (pour calcul coût)
  • sensor.teleinfo_energy : Sommes des 2 index HC et HP (pour calcul consommation Wh)
  • sensor.teleinfo_energy_yesterday : consommation de la veille
  • sensor.teleinfo_energy_total : consommation totale depuis initialisation du module (reset manuel, peut-être programmé en début d'année pour calculer une consommation annuelle avec Tasmota)
  • sensor.teleinfo_periode_tarifaire : période tarifaire (pour calcul coût)

Avec tout cela vous pouvez avoir le suivi d'énergie journalier global de votre installation avec ces sensors. A coupler avec un utility_meter pour avoir le suivi. Il est possible d'y associer le coût, en ajoutant à HA les informations de votre abonnement (la séparation HC/HP est faites pour ça !)

Amusez-vous bien !

Sources

 

Home Assistant & ZigBee

ZigBee est un protocole de haut niveau permettant la communication d'équipements personnels ou domestiques équipés de petits émetteurs radios à faible consommation ; il est basé sur la norme IEEE 802.15.4 pour les réseaux à dimension personnelle (Wireless Personal Area Networks : WPAN). Wikipédia et Google vous raconteront le reste... Mais sous Home Assistant il y (principalement) trois façons d'approcher Zigbee :

Deconz / Phoscon

La clé Combee II dépend ici de l’environnement logiciel de son editeur, qu'il soit installé de façon indépendante ou plus ou moins mergé à Home Assistant (ou une autre solution). C'est donc une une solution qui peut s'utiliser de façon autonome, ce qui était leur but de départ, remplacer simplement quelques passerelles propriétaires (Hue, Ikea, etc..). ils fournisse d'ailleurs des images RPI pour se passer de leur boitier et c'’est d'ailleurs ainsi que je l'avait monté sur un RPI2 auquel j'accédait depuis Jeedom, et auquel j'accède maintenant avec Home Assistant.

Le fait que ce soit autonome permet de réaliser des opérations sans passer par une plateforme domotique, tout en disposant des équipements sur une ou plusieurs solutions domotique. Par exemple, pour associer un interrupteur avec une ampoule, il est plus simple de le faire sous Phoscon, sachant que de toutes façons l'état de l'ampoule remontera dans Home Assistant et que je pourrais toujours l'éteindre avec une automation...

Enfin, les équipements sont également accessibles en parallèle depuis Alexa...

C’est donc la solution la plus proche d'une passerelle propriétaire, de ses avantages, de sa façon de fonctionner et d'évoluer. C’est celle que je conseillerais pour installer un HA chez un tiers, la plus grand public qui s'appuie sur des équipements l'ont peut facilement acquérir dans le commerce.

ZHA

Zigbee Home Automation est la solution la plus intégrée à Home Assistant. Elle s'appuie sur à peu près toutes les clés Zigbee du marché et fonctionne plutôt bien. Par contre ici on est sur une intégration fermée dans et pour HA. Elle supporte (à titre expérimental) même la Zigate dont j'avais fini par me débarrasser sous Jeedom...

Rien à ajouter de plus, pour faire simple et rester dans HA c’est la solution à adopter et l'on retrouvera les menus de configurations dans la configuration HA

zigbee2mqtt

C'est la solution à la mode, parce que MQTT est à la mode. Mais au delà de l'effet de mode, MQTT est le protocole qui fait son chemin et risque de devenir un standard bien au delà de nos petits bricolages domotique. Ici on passe par une passerelle que l'on va monter ou on le souhaite (RPI Zero indépendant, HA remote, etc...), qui va transmettre ses infos à un brooker qui lui aussi peut être n'importe ou (LAN/WAN) et notre HA ne sera qu'un client de ce brooker. L'étape suivante étant bien sur que les équipements intègrent ce protocole, ça arrive, notamment sur du DIY avec le firmware Tasmota et on peut imaginer que le marché adopte MQTT, c’est d'ailleurs le cas des équipements Shelly en WI-FI qui proposent (timidement) ce protocole de façon native, ou d'autres passerelles comme ble2mqtt...

Pour revenir à zigbee2mqtt le projet est très actif, plutot stable et c'est par exemple le seul qui propose les mises à jours bios de certains équipements. Pour ce test je l'ai monté sur un HA remote et j'ai utilisé une intégration sous forme d'addon. En fait simplement parce que j'avais ce HA remote sous la main, mais pour le coup la com ne se fait pas en remote mais en MQTT. C'est une solution ultra paramétrable, chaque équipement est ajustable à la source et les infos remonteront vers les clients, je dis bien les clients car on peut tout à fait imaginer qu'in équipement soit utilisable avec plusieurs solutions, un capteur de température vu par HA mais aussi par une solution externe, etc...

A noter que contrairement aux deux précédentes solution j'ai bien la remontée de l'état des piles sur les révisions récentes (fin 2019) des capteurs Aqara, ce n'est toujours pas les cas des deux solutions concurrentes, preuve de plus que le projet est très actif.

Enfin zigbee2mqtt s'appuie sur une clé DIY, ce qui veut dire qu'il faudra bricoler un peu et acheter quelques accessoires. Mais ça reste easy !

Alternatives...

D'autres continuent à utiliser l'intégration Xiaomi avec la passerelle de première génération. Ça fonctionne, mais pour moi ce n'est pas une solution Zigbee, mais une solution Xiaomi qui repose sur l'utilisation d'un serveur Chinois, dépendant de la volonté de Xiaomi d'en laisser l'usage détourné possible, voire de la Chine de laisser passer ou non les flux. Si le fonctionnement se fait en local, c’est également un potentiel cheval de Troie, mais ça c'ets un autre débat. Vous aurez compris que je ne suis pas fan.

Conclusion

Conclusion il faut choisir. Choisir n'est jamais simple, et en l'espèce ce n'est pas moi qui vais vous dire quoi choisir ! Il faut tout de même savoir que si les produits les plus courants sont supportés par toutes les solutions, d'autres plus confidentiels ne le seront que par l'une ou l'autre.

Sources