Home Assistant & Nuki

Ca me travaillait depuis un moment, automatiser la porte d'entrée ! L'objectif étant que la porte se verrouille quand je part (process d'alarme, fermeture des volets, etc.) et se déverrouille quand j'arrive avec le process inverse. Accessoirement permettre à des tiers d'ouvrir (clavier et tags), ou moi même d'ouvrir et fermer à distance.

J'ai regardé un peu le marché et j'ai trouvé :

  • Linus Yale : un peu trop américaine, et de fait encombrante !
  • Tedee : tentant mais un peu jeune (test ici)
  • Danalock : on dirait qu'ils ne bougent plus trop...
  • Nuki : mon choix par défaut !
  • Et enfin beaucoup de chinoiseries que je préfère éviter pour ce genre d'objets...

Après avoir bien creusé le sujet et écouté les conseils d'autrui j'ai porté mon choix sur une Nuki Pro 4.0, en y voyant comme avantage :

  • Du WIFI intégré afin d'éviter un bridge supplémentaire
  • Un bloc de batterie rechargeable
  • Une meilleure finition
  • Matter, enfin, un jour peut être...

Je fait l'impasse de l'installation qui est effectivement facile, mais qui m'a tout de même couté un cylindre débrayable. Et on passe à la configuration.

Je n'ai pas grand chose à redire sur la mise en œuvre via l'application, c'est plutôt bien fait, tout comme Nuki Web ou l'accès à distance depuis un smartphone. Là ou ça va se compliquer c'est pour intégrer ça à Home Assistant, et c'était le but ! Il existe plusieurs solutions et je veux bien comprendre que les débutants soient perdus.

Intégration du Core HA

On me l'a déconseillé et j'en ai lu du mal, j'ai donc zappé.

Intégration Nuki NG

Ca semble bien fait, mais c'est un fail. Je pense qu'il vaut mieux disposer du bridge Nuki.

Intégration Nuki BT

Il s'agit d'un fork de Nuki NG qui a la particularité de se connecter directement au Nuki en Bluetooth. A priori parfait pour mon usage. Sauf que je n'ai jamais réussit à appairer le Nuki à cette intégration.

MQTT

Proposé comme la solution officielle pour connecter Nuki à Home Assistant, je me suis dit que ça serait facile. En effet la configuration est simple et les information de base (Look/Unlook et batterie) remontent bien dans Home Assistant. Il faut laisser le WIFI actif, ça consommera un peu plus mais ça devrait aller.

Oui, mais ! Il y a un tout petit problème : entre l'envoi d'une commande, l'action et le retour d'état il peut se passer de 1 à 3 minutes (quand ça fonctionne). Et je ne me voit pas passer 3 minutes à attendre devant la porte... Que se passe t'il ? Direction le forum Nuki, et la c'est le bug ! Problème plus ou moins connu, récurent, bref les utilisateurs ne sont pas contents et j'aurais du lire ça avant. Bien sur Nuki explique que ça vient du Wi-Fi des utilisateurs, sauf que j'ai testé avec mon Unifi de base et 3 AP d'autres marques, avant de me dire que si l'application Nuki connectée sur un smartphone en 4G fonctionnait bien, le problème n'était pas lié au Wi-Fi mais à l'implémentation MQTT. Un peu dégouté, je me suis dit qu'ils voulaient vendre leur bridge et que n'y couperait pas !

MQTT via ESP Nuki HUB

Dans mes pérégrinations j'a commencé par tester sans succès un projet basé sur espHome avant de tomber sur Nuki Hub, un projet très complet qui crée un bridge avec un ESP. Nuki Hub communique avec un Nuki Lock, un Opener et un clavier via Bluetooth (BLE) et utilise MQTT pour s'intégrer à d'autres systèmes. Il expose l'état de verrouillage (et bien plus encore) via MQTT et permet d'exécuter des commandes telles que le verrouillage et le déverrouillage via MQTT (n'hésitez pas à bien lire la doc qui est une mine d'informations).

Un petit flash plus loin j'ai réussit à associer mon Nuki à ce bridge DIY, il remonte toutes les informations utiles, voire plus, et surtout il permet de verrouiller / déverrouiller rapidement la serrure, ce qui est tout de même la base.

Par contre il faut savoir une chose, chez Nuki c'est fromage ou dessert, pas le deux ! En gros pour activer un bridge, qu'il soit Nuki ou DIY, il faut désactiver le Wi-Fi du Nuki. Ce qui concrètement veut dire qu'on ne pourra plus le commander à distance depuis l'application Nuki et que si on veut utiliser localement cette application il faudra se rapprocher du Nuki, la portée du Bluetooth de cet objet étant très faible (j'ai du mal dans mon bureau qui est à 3 mètres de la porte d'entrée...).

Conclusion

Ou moralité ! Je crois que j'ai acheté une version 4 et Pro pour rien. En effet le Wi-Fi intégré ne me servira à rien et une v3 standard aurait parfaitement fait le job pour pas cher (il y a pas la sur le Bon Coin !

Home Assistant & Sirènes

J'ai déjà parlé ici du système d'alarme Alarmo pour Home Assistant et notamment des commandes possibles pour armer et désarmer le système. Aujourd'hui il s'agira des sirènes.

J'ai trois modèles

  • La plus basique est juste branchée sur une prise commandée Zigbee ondulée. Donc un switch: vu en tant que siren:.
  • Une sirène Heiman qui sous ZHA décroche régulièrement et que j'ai du appairer à ma seconde passerelle sous Z2M.
    • Sous ZHA elle était vue en tant que siren:.
    • Sous Z2M elle est vue en tant que rien du tout...
  • Une sirène SMaBit sous Z2M également vue en rien du tout...

Pour commander une sirène via ZHA HA propose :

    - service: siren.turn_on
      target:
        entity_id:
          - siren.heiman_sirene

Pour commander une sirène sous Z2M il faut lui envoyer le payload correspondant :

    - service: mqtt.publish
      data:
        topic: zigbee2mqtt/Sirène SMaBiT/set
        payload: >-
          {"warning": {"mode": "fire", "level": "very_high", "strobe_level": "low", "strobe": "false", "strobe_duty_cycle": "10", "duration": "360"}}

Un peu plus compliqué et moins facile à mémoriser, mais ça fonctionne.

Mon objectif a donc été de faire en sorte qu'une sirène Z2M soit vue par Home Assistant comme une sirène ZHA et ainsi pouvoir la commander par un siren.turn_on comme les autres... Et voici ce que ça donne :

mqtt:
  siren:
    - unique_id: heiman_sirene_1s
      name: Heiman Sirène 1s
      state_topic: "zigbee2mqtt/Heiman Sirène 1/set"
      command_topic: "zigbee2mqtt/Heiman Sirène 1/set"
      optimistic: false
      qos: 0
      retain: true
      state_value_template: "{{ value_json.warning['mode'] }}"
      command_template: '{"warning": {"duration": 2, "mode": "burglar", "level": "very_high", "strobe": true}}'
      command_off_template: '{"warning": {"duration": 2, "mode": "stop", "level": "very_high", "strobe": true}}'
      state_on: "burglar"
      state_off: "stop"

Problème, car il y en a un, la sirène Heiman ne retourne aucun état sous Z2M. Il y a beaucoup d'articles à ce sujet, et l'intégration ne semble pas vraiment terminée. Hors dans l'activation il y a une durée, le principe étant d'activer la sirène pour x secondes. Et donc comme elle ne retourne pas son état, son commutateur restera sur ON alors que le délais d'activation est terminé et la prochaine action n'aura aucun effet... De plus certaines sirènes proposent plusieurs fonctions et tonalités (les bips de délais d'armement et désarmement par exemple).

Donc contrairement à ZHA ou l'intégration siren: peut gérer tous les modes, chercher à gérer une sirène Z2M en tant que siren: n'a pas de sens... (hormis peut être de bricoler un template: qui en fonction de la durée d'activation repasserait le commutateur à off, on peut aussi le faire via une automation: mais là ça va alourdir la chose...).

Alternative

S'agissant d'envoyer un payload à une sirène Z2M, ce que j'ai trouvé de plus logique est un mqtt:/button: et il faut donc en faire deux :

mqtt:
  button:
    - unique_id: siren_heiman_1_warning
      name: "Sirène Heiman 1 : Waraning"
      command_topic: "zigbee2mqtt/Heiman Sirène 1/set"
      payload_press: '{"warning": {"duration": 2000, "mode": "burglar", "level": "very_high", "strobe": true}}'
      qos: 0
      retain: false
      entity_category: "config"
      device_class: "restart"

    - unique_id: siren_heiman_1_stopped
      name: "Sirène Heiman 1 : Stopped"
      command_topic: "zigbee2mqtt/Heiman Sirène 1/set"
      payload_press: '{"warning": {"duration": 2, "mode": "stop", "level": "very_high", "strobe": true}}'
      qos: 0
      retain: false
      entity_category: "config"
      device_class: "restart"   

Ou plusieurs pour gérer les différents mode de la SMaBit :

mqtt:
  button:
    - unique_id: siren_smabit_armed
      name: "Sirène SMaBit : Armed"
      command_topic: "zigbee2mqtt/Sirène SMaBiT/set"
      payload_press: '{"squawk": {"state": "system_is_armed", "level": "veryhigh", "strobe": "true"}}'
      qos: 0
      retain: false
      entity_category: "config"
      device_class: "restart"

    - unique_id: siren_smabit_disarmed
      name: "Sirène SMaBit : Disarmed"
      command_topic: "zigbee2mqtt/Sirène SMaBiT/set"
      payload_press: '{"squawk": {"state": "system_is_disarmed", "level": "veryhigh", "strobe": "true"}}'
      qos: 0
      retain: false
      entity_category: "config"
      device_class: "restart"

    - unique_id: siren_smabit_warning
      name: "Sirène SMaBit : Warning"
      command_topic: "zigbee2mqtt/Sirène SMaBiT/set"
      payload_press: '{"warning": {"mode": "fire", "level": "very_high", "strobe_level": "low", "strobe": "false", "strobe_duty_cycle": "10", "duration": "360"}}'
      qos: 0
      retain: false
      entity_category: "config"
      device_class: "restart"

    - unique_id: siren_smabit_stopped
      name: "Sirène SMaBit : Stopped"
      command_topic: "zigbee2mqtt/Sirène SMaBiT/set"
      payload_press: '{"warning": {"mode": "stop"}}'
      qos: 0
      retain: false
      entity_category: "config"
      device_class: "restart"

Vous l'aurez compris, il s'agit plus d'un exercice de style qu'autre chose. Mais ça m'aura permis de comprendre comment créer des devices MQTT non reconnus par le discovery:. Merci @Mathieu pour ta participation !

Sources

 

Home Assistant & Coupures secteur

Ceux qui habitent à la campagne le savent, le réseau ERDF/Enedis est dans un état suffisamment lamentable pour que la moindre intempérie provoque des coupures électriques. Par ailleurs il peut arriver que pour une raison ou une autre un différentiel saute. Et ces coupures on un impact sur toute installation domotique, si sur certains appareils on peut gérer le comportement lors de la reprise électrique (Shelly par exemple) ce n'est pas le cas de beaucoup d'ampoules ou de prises commandées (Tuya pour le mauvais élève), il faudra donc gérer ce que l'on fait lors de la reprise en domotique et / ou être avertit en cas d'absence afin de mandater quelqu'un pour réarmer le différentiel du congélateur...

Et pour ça il faut que Home Assistant soit très rapidement informé sur les points de coupure possibles afin par exemple de sauvegarder et restaurer un état comme j'en avait parlé ici. Chez moi je dénombre 4 point de coupures. Le disjoncteur général + 4 disjoncteurs différentiels (1 par étage de mon tableau électrique).

Il me fallait donc un système qui me permette de tester la non présence électrique sur ces 5 points de coupure. Pour y parvenir j'ai commandé une carte qui comporte 8 optocoupleurs (lien non sponsorisé) (ça existe en 1, 3 et 8 canaux) que je vais pouvoir exploiter en GPIO. Le principe est simple, si présence électrique en entrée le port passe à 1.

Au départ je comptais exploiter ça sur le Raspberry qui me sert en remote pour le Zigbee et BLE avec l'intégration GPIO idoine, mais ce n'était pas assez réactif, j'ai donc opté pour un ESP que j'avais sous la main, et c'est ainsi que j'ai mis le doigt dans Tasmota, chose dont je connaissait l'existence grâce à @mathieu qui en fait une promotion quasi sectaire, mais que je n'avais jamais exploré...

ESP8266

Ce module présente l'avantage de s'alimenter en Micro USB, avantage car on a tous dans nos tiroirs des chargeurs et des câbles dans ce format. C'est également avec ce câble que l'on va le brancher sur un PC afin de le Tasmotiser (pas sur que l'Académie ajoute ce verbe cette année). Pour le reste, je ne suis pas spécialiste pour vous parler de ses avantages et inconvénients, ah si, il était présent au fond de mon tiroir.

On lance tasmotizer.exe (ça existe pour d'autres confessions que Windows) et le reste se fait tout seul, ça va même télécharger le firmware idoine. Presque trop facile. Une fois que c'est fait alimente l'ESP et on se connecte dessus en WI-FI afin de renseigner notre SSID dédié IoT. Après un redémarrage on peut ouvrir avec un navigateur et débuter la configuration du module. Je vous laisse trouver comment repérer l'IP et lui faire une réservation DHCP.

Tasmota

Dans la configuration on commence par choisir le type de module (Generic 18) et on configure 5 GPIO en mode SWITCH. Attention tous les ports ne sont pas utilisables, il faut tâtonner un peu quand on ne connait pas la signification des options possibles.

Ensuite on va passer à la configuration MQTT (Host, port, user et password). Et c'est tout. Enfin, il faut tout de même connecter notre carte optocoupleur avec l'ESP avec des câbles Dupont (+3.3, GND et GPIO 1 2 3 4 5).

Intégration

Sous Home Assistant il a plusieurs façons d'exploiter Tasmota (voir ici), en mode pur MQTT pour intégriste barbu (au sens Geek du terme hein !) en déclarant les devices en YAML, en mode MQTT discovery et depuis peu avec l'intégration Tasmota officielle qui va s'appuyer sur MQTT pour créer les devices et les entities. Comme je ne suis pas barbu et que je pense qu'il faut s'ouvrir au plus grand nombre, vous imaginez bien que j'ai choisit cette option.

On ajoute l'intégration avec le bouton + dans les intégrations et on laisse les options de base.

Ensuite on va dans la console du module Tasmota afin de saisir quelques options (que l'on pourrait du reste envoyer en MQTT ou en HTTP...).

SetOption19 0 # Pour lui dire de ne pas faire du discovery en MQTT mais via l'intégration Tasmota

SetOption114 # Pour activer le mode switch

SwitchMode1 2 # Mode folow inversé (0 = on, 1 = off) sur switch 1
SwitchMode2 2 # Mode folow inversé (0 = on, 1 = off) sur switch 2
SwitchMode3 2 # Mode folow inversé (0 = on, 1 = off) sur switch 3
SwitchMode4 2 # Mode folow inversé (0 = on, 1 = off) sur switch 4

Normalement à ce stade il ne nous reste plus qu'à tester notre montage en alimentant chacun des ports en 220 V. Attention, on ne le répètera jamais assez, le 220 V c'est très dangereux, donc on prend ses précautions (et si on ne le sent pas on retourne jouer à la marelle avec ses copines !). Moi je décline bien sur toute responsabilité.

Vous devriez rapidement obtenir quelque chose qui ressemble à ça :

Usage

Il ne restera ensuite plus qu'à exploiter ces binary_sensor: pour des actions ou des notifications, et pour ça je vous conseille l'intégration alert...

alert:
  tableau_1:
    name: Diff 1
    entity_id: binary_sensor.switch2
    state: 'off'   # Optional, 'on' is the default value
    repeat:
      - 10
      - 30
      - 60
      - 300
    can_acknowledge: true  # Optional, default is true
    skip_first: true  # Optional, false is the default
    message: "{{ states.sensor.date_time.state}} > ALERTE | Différentiel 1 : OFF" 
    done_message: "{{ states.sensor.date_time.state}} > ALERTE | Différentiel 1 : OK"
    notifiers:
      - slack_hass_canaletto
      - Free_Mobile

Voilà, presque trop simple. Et merci à ceux qui m'ont aidé à cogiter tout ça !

 

Home Assistant & Shelly

Il y a un an quand j'ai commencé à utiliser des Shelly sous Home Assistant l'évidence était d'utiliser l'intégration tierce Shelly4HASS. Depuis la compatibilité MQTT s'est bien améliorée et j'y ait trouvé un intérêt, alors même  que les équipes de Home Assistant ingéraient le support natif de Shelly au core. Donc aujourd'hui il n'y a plus vraiment d'intérêt à utiliser cette intégration tierce, toujours dans la logique de faire au plus simple. Bien que Shelley4HASS fonctionne toujours très bien et présente l'avantage de fournir beaucoup d'informations dans les attributs.

Deux options

  1. Vous débutez en domotique ou vous voulez juste allumer deux ampoules et actionner un relaie. Laissez vous guider, HA découvrira vos modules et vous les piloterez en deux clics afin d'n exploiter toutes les possibilités, l'intégration de base supporte toutes les possibilités et s'améliore de releases en releases.
  2. Vous passez vos nuits sur votre serveur domotique, vous fréquentez des barbus qui vous poussent à souder des cartes électroniques, votre facteur vous regarde bizarrement depuis que vous recevez plusieurs fois par semaine des paquets en provenance de Chine. Attention, bientôt vous n'aurez plus de famille, d'ailleurs votre femme pense à demander le divorce. Mais faites vous plaisir prenez la route MQTT, en attendant de retrouver la votre, c'est aussi une forme de liberté.

Je ne vais pas vous expliquer MQTT, d'autres l'ont fait, mais MQTT est un vrai protocole domotique en devenir. Attention toutefois, chez Shelly, c'est Cloud (App mobile, Alexa, GH) ou MQTT. Il faut choisir. Attention également aux modules Shelly fonctionnant sur piles, personnellement j'ai abandonné ces modules car même avec du WI-FI Low Energy les piles sont trop rapidement à changer, et il y a des chances qu'en MQTT ce soit encore pire. Donc pour les sondes et autres capteurs, Zigbee est à mon sens plus adapté.

MQTT sur Home Assistant

Je ne vais pas détailler ici l'a mise en œuvre de MQTT, ce n'est pas le propos, mais en gros on installe un broker (dans les adons) et ensuite on ajoute l'intégration MQTT depuis la page des intégrations. Et si on ne veut pas se taper la configuration individuelle des modules, on installe Shelly Discovery qui est un script Python qui va le faire pour vous. Pourquoi ça alors que d'autre modules vont en MQTT créer tout ce qui est nécessaire sous HA ? Simplement parce que Shelly se veut générique et ainsi ils n'ont pas à gérer cette partie. Ca se défend.

Migration vers MQTT

On commence par imprimer une liste des Shelly existants sous Shelly4HASS avec leur adresse et leur usage afin de pouvoir les repérer en MQTT.

Dans l'intégration MQTT qui a remonté nos modules c'est le moment de penser au renommage. C'est un point important et il sera bien moins aisé d'y revenir. Il y a plusieurs écoles.

  • Renommage soft ou on renomme juste le display name.
  • Renommage hard ou l'on renomme le display name et l'entité. Dans ce cas il faut le faire avant d'aller faire le travail suivant car ça aura des conséquences sur le travail d'intégration.
  • Renommage unique du display name de l'entité qui actionne (light ou switch). Ca sera utile pour le présenter dans Alexa ou GH.
  • Dans tous les cas il ne faut pas oublier d'affecter une pièce (qui sera également reprise dans Alexa et GH)
  • Et sur la config des Shelly de type relais (1, 1PM, 2.5 ou prises) utilisés pour les éclairages, aller dans Appliance type et changer general pour light.

A ce stade on veut virer Shelly4HASS dans les intégrations et aussi le composant dans HACS. Avantage on va voir tout de suite ce qui ne fonctionne plus. Mais on peu aussi le faire après avoir migré en MQTT si on ne pense pas pouvoir faire ce travail d'une traite. Quand Shelly4HASS n'est plus présent on va voir remonter automatiquement les modules via l'intégration de base Shelly. On peut éviter ça si on en a beaucoup ou simplement clique sur ignorer dans les intégrations.

discovery:
  ignore:
    - shelly

Ensuite il va falloir de la patience et comme toujours de la rigueur.

Point à vérifier pour chaque module :

  • S'ils sont affichés dans Lovelace (relais et conso).
  • S'ils sont télécommandés (par quoi, automation, BP ou ComanderX).
  • S'ils sont déclarés en utility_meter:
  • S'ils sont utilisé dans les automations ou des thermostats
  • S'ils sont utilisés dans d'autres cas particuliers.

On les faits les uns après les autres et on valide chaque étape en en vérifiant le bon fonctionnement.

Bienvenue dans MQTT !

En bonus, MQTT Explorer qui sera bien utile pour mettre au point des choses complexes et vérifier ce qui se trame sur votre broker. Broker que l'on a ici monté sur HA, mais qui dans l'absolu pourrait être sur une autre machine, un NAS, voire même sur un autre site. Il existe d'ailleurs des brokers publics pour faire communiquer différents objets entre eux. Vous allez me dire que c'est une façon de recentraliser l'information, oui, mais ça peut être nécessaire en IoT avec des objets volatiles car si l'objet A ne parvient pas à joindre l'objet B, le broker conservera alors le message le temps que l'objet B soit disponible... D'où l'intérêt d'une certaine centralisation qui peut d'ailleurs être répartie...

EDIT : un article très bien fait : https://henriksozzi.it/2021/02/shelly-e-home-assistant/ (clic droit traduire si vous ne maitrisez pas l'italien...)

 

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 éditeur, 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 !

EDIT 22/01/2021 : Pensez à mettre à jour le firmware de vos clés, ça fonctionnera mieux avec les dernières versions...

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'est un autre débat. Vous aurez compris que je ne suis pas fan.

EDIT 22/01/2021 : SLS, vous risquez d'en entendre parler cette année...

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