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, RC & Lights

Me voici bien installé sous Home Assistant, j'ai choisi au départ Zigbee pour les capteurs de température et d'ouverture, puis au hasard des pubs sur Ali Express et de mes passages chez Ikea j'ai acheté diverses télécommandes en me disant que j'en ferait bien quelque chose... L'usage principal étant de piloter des éclairages ou des scènes, du son, ou encore une action du genre "chauffe la salle de bain" et dis à Alexa de me prévenir quand la température sera idéale". Bien sur on peut remplacer les télécommandes par Alexa ou GH, mais ça me fait toujours bizarre de parler à ces objets, surtout quand je ne suis pas seul...

Bref, pour piloter un éclairage depuis une télécommande Zigbee il existe plusieurs approches plus ou moins facile à mettre en œuvre. On part du principe que Zigbee s'appuie sur ZHA, Zigbee2Mqtt, Deconz ou directement en MQTT.

Phoscon

Il s'agit ici de l'interface de Deconz qui est la solution la plus répandue et à mon gout la plus performante. Cette passerelle va plus loin que les autres en ce sens qu'elle intègre une interface qui permet facilement d'associer les touches d'une télécommande à des ampoules ou des prises. En fait au départ Phoscon est juste fait pour remplacer les passerelles propriétaires (Hue, Ikea, etc.) sans pour autant disposer de Home Assistant et il est même possible de créer des scènes et de disposer des fonctionnalités des passerelles émulées.

C'est donc la solution idéale quand on ne dispose que d'ampoules ou prises Zigbee, d'autant plus que ces éléments seront toujours disponibles sous HA pour d'autres actions et que cette passerelle est compatible Alexa. Personnellement je recommande l'installer sur un vieux RPI à part et ainsi la placer au centre du logement.

Automations

Mais, ça va se compliquer quand on va vouloir associer une télécommande Zigbee à un équipement non Zigbee. J'ai par exemple quelques variateurs Shelly et je voulais y associer une télécommande Opple afin de plus bouger mon cul du canapé, bien que dans la vraie vie je passe tout de même plus de temps dans mon fauteuil de bureau.

La solution consiste donc à écrire des automations en se basant sur les devices et les codes retournées par ces télécommandes. C'est long, fastidieux et encombrant quand on sait qu'il faut 4 automations pour gérer les fonctions de base d'une ampoule variable , et je ne parle pas de la gestion des couleurs. C'est lourd, mais ça fonctionne à coup de copié / collé, et le faire sous NodeRed sera tout aussi fastidieux.

ControlerX

Alors j'ai longtemps laissé ces télécommandes en déshérence, puis un soir je me suis mis à explorer la communauté HA (celle en anglais) à la recherche d'une alternative, et je suis tombé sur ControlerX. Au départ je n'ai pas aimé car ça s'appuie sur AppDaemon qu'il me fallait installer, ce qui alourdit mon serveur HA. Et puis en lisant je me suis dit que ça valait le coup de creuser la chose.

Je vous laisse installer AppDaemon 4, c'est un AddOn qui s'installe comme les autres depuis le superviseur sur Hassio. On peu aussi l'installer en Docker pour ceux qui aiment se compliquer la vie. Il faut juste créer un fichier de config basic qui sera suffisant pour ce que l'on va en faire dans :

secrets: /config/secrets.yaml
appdaemon:
  latitude: 52.379189
  longitude: 4.899431
  elevation: 2
  time_zone: Europe/Paris
  plugins:
    HASS:
      type: hass
http:
  url: http://127.0.0.1:5050
hadashboard:
admin:
api:

/config/appdaemon/appdaemon.yaml

Ensuite on va installer ControleurX depuis HACS et une fois fait créer le fichier de config, non pas de ControlerX mais des apps AppDaemon :

sejour_halogène: 
  module: controllerx
  class: WXCJKG13LMLightController
  controller: aqara_opple
  integration: deconz
  automatic_steps: 30
  mapping:
    3001: hold_brightness_toggle
    3002: toggle
    3003: release
    3004: toggle_full_brightness
    3005: toggle_min_brightness
  light: light.shelly_shdm_1_f3758  

/config/appdaemon/apps/apps.yaml

Et la lumière fut ! Ces quelques lignes assurent les 5 fonctions d'une touche de ma télécommande qui en comporte 6. Et encore ici j'ai choisit un mapping personnalisé car je souhaite que chaque touche ne commande qu'un seul point lumineux en me servant du multiclic, mais ça serait encore plus simple si je voulais juste reproduire les fonction d'une télécommande Ikea ou Hue avec l'ampoule ivrée avec.

Explications lignes par lignes :

  1. un nom d'app que vous choisissez.
  2. le nom du module AppDaemon, ici ControlerX.
  3. le code de la télécommande utilisée : ici le controleur Opple avec 6 boutons (ici la liste des contrôleurs supportés).
  4. l'ID du device fournit par la passerelle (controller_id ou adresse IEEE (voir ici comment récupérer cette information).
  5. L'intégration utilisée (deconz, mqtt, zha, state) (plus d'informations ici).
  6. Des options (multiple_click_delay: 500, delay: 50, automatic_steps: 30, manual_steps: 10 (je vous laisse cherche run peu car il y en d'autres).
  7. Les mapping, ce qui qui va consister à associer les codes envoyés par la télécommande aux fonctions possibles.
  8. Enfin, on pointe sur l'éclairage déclaré dans Home Assistant, ici un Dimmer Shelly.

Je n'ai parlé ici que de ce que j'ai utilisé. Mais ControlerX va beaucoup plus loin. Il est bien sur possible de piloter des scènes, des automation ou encore des lecteurs multimédia, et par exemple d'associer le bouton rotatif Ikea à votre lecteurs Sonos. Je vous conseille la lecteur du sujet dédié et bien sur de la doc sur GitHub, même si ce développeur est bien dans le codage de ses url qu'il faudra souvent reconstituer...

 

Home Assistant & Enedis

Dans le grand foutoir de la pseudo concurrence des fournisseurs d'électricité on trouve Enedis qui gère les infrastructures et vous colle d'autorité un compteur Linky. On ne va pas parler ici des polémiques que cela à suscité, sa dangerosité sanitaire est très certainement moindre que toutes les technologies que nous utilisons, tout au moins pourrais t'on s'interroger sur son cout global qui sera nécessairement répercuté sur les clients.

Ce qui m'intéresse ici c'est ce que l'on peut en faire. Enedis remonte en temps (presque) réel (toutes les heures) les informations de consommation et on peut donc imaginer qu'il est possible de récupérer facilement ces informations qui après tout nous appartiennent. En fait ce n'est pas si simple et il semblerait que ce soit tout le contraire, Enedis faisant tout pour en limiter l'usage à la consultation de son piètre site web, tout en ayant certainement une arrière pensé de monétisation possible... Ainsi, au fil du temps, les diverses extensions permettant la récupération de ces informations ont été mises en échec.

A ce jour, et d'après mes informations, la règle est que seule une société a la possibilité de demander un accès (gratuit pour l'instant) à l'API. Ca limite fortement nos habitudes de DIY !

Alors un développeur de la communauté (M4dm4rtig4n) a eu la riche idée, un projet personnel qui se sert de la façade légale de son employeur, de monter une passerelle d'accès : https://enedisgateway.tech. On lui fait confiance, il fera tout pour assurer la confidentialité des données, mais l'utilisation de cette passerelle sous entend de confier l'accès à vos données à cette société. Le risque est faible, les données peu sensibles, le jeton est révocable, et surtout rien ne vous force à utiliser cette passerelle qui pour l'instant est la seule solution fonctionnelle.

Dans la pratique

On commence, si ce n'est pas fait, par créer un compte sur le site Enedis et y associer votre compteur Linky. Attention, j'espère qu'Enedis maitrise mieux le réseau électrique que le CSS car il y a pas mal de bugs et il vaudra mieux faire tout ça avec Firefox, car aléatoirement ça ne passe pas sous Edge ou Chrome (qui est juste le navigateur le plus utilisé au Monde). Ensuite on se rend sur la passerelle (https://enedisgateway.tech) et on crée un token qui aura cette forme :

Votre token : 1ETPfWPjxmkHe2GfsggdfhdgfshgfhgfNRKnhdgfhMpOrGzKe3i

Vos points de livraison : 258465654641

Il ne faut pas oublier d'activer l'enregistrement de la consommation horaire et de sa collecte si on veut disposer des infos HP/HC. Une commande de test est fournie, elle permettra de vérifier que ça fonctionne avant de passer à la suite

curl -X POST https://enedisgateway.tech/api -H 'Authorization: 1ETPfWPjxmkHe2G2hj87w8shfgsdfghsdfghhsfghgfhjsfOrGzKe3i' -H 'Content-Type: application/json' -d '{"type": "consumption_load_curve","usage_point_id": "25464656546695","start": "2020-11-10","end": "2020-11-11"}'

A partir de là on peu repasser sous Home Assistant et installer dans HACS deux Custom repositories créés par un autre développeur de talent (saniho) de la communauté HACF, qui correspondent d'une part à un composant qui va créer un sensor personnalisé, et d'autre part une carte pour Lovelace.

Une fois ces deux installations terminées on redémarre Home Assistant, et on crée le sensor, ce qui nécessitera un nouveau redémarrage.

sensor:
    - platform: myEnedis
      token: fTEHWCldfsgsdfghsjdhjdFGHJFHSDHDSFGhfdfhNfWqwCE3
      code: 464554438199434
      heures_creuses: "[['00:00','05:00'], ['21:30', '24:00']]"
      hc_cout: 0.1337
      hp_cout: 0.1781
      scan_interval: 3600
      delay: 7200  # OPTION

Après un redémarrage et le temps que tout se mette en place, le sensor.myenedis devrait nous retourner ces informations :

attribution: ''
version: 1.0.2.5
lastSynchro: '2020-11-20T23:51:21.456065'
lastUpdate: '2020-11-20T23:51:21.456048'
timeLastCall: '2020-11-20T23:51:21.456021'
yesterday: 53347
last_week: 240629
day_1: 53347
day_2: 42741
day_3: 42420
day_4: 30767
day_5: 36311
day_6: 35932
day_7: 32130
daily:
  - 53.347
  - 42.741
  - 42.42
  - 30.767
  - 36.311
  - 35.932
  - 32.13
halfhourly: []
offpeak_hours: 19.947
peak_hours: 33.4
peak_offpeak_percent: 62.60895645490843
yesterday_HC_cost: 2.6669139000000004
yesterday_HP_cost: 5.94854
daily_cost: 8.6154539
current_week: 169275
last_month: 909684
current_month: 702447
last_year: null
current_year: 2670999
errorLastCall: >-
  {'error': 'result_404', 'enedis_return': {'error': 'no_data_found',
  'error_description': 'no measure found for this usage point', 'error_uri':
  'https://bluecoder.enedis.fr/api-doc/consulter-souscrire'}}
monthly_evolution: 0
unit_of_measurement: kWh
friendly_name: myEnedis

Vous pourrez utiliser ces données à souhait, ce sont des attributs, mais le plus simple reste de créer une carte custom et on y coller ça :

type: 'custom:content-card-linky'
entity: sensor.myenedis
showInTableUnit: false

Et le résultat est tout de suite bien plus lisible. Voilà. Et pour suivre le projet ça se passe ici sur HACF.

Alternatives

Ici je vous ai parlé d'une solution native dans Home Assistant. Mais les afficionados de NodeRed vous diront que non, que c'est nul et qu'il faut le faire en NR. Vu que je ne parle jamais de NodeRed, vous avez déjà compris que je ne suis pas fan, même si j'ai pas mal testé et que je trouve le concept génial, pour l'heure je préfère me cantonner au YAML, après tout j'en ai bien chié pour comprendre, et comme disais ma tante qui n'avais jamais eu de descendance, je ne vais pas jeter tout de suite le bébé avec l'eau du bain ! Mais bon, pour ceux qui veulent faire tout ça avec NodeRed, ça se passe ici, toujours sur HACF.

Une autre possibilité est de se servir de la prise Teleinfo que l'on trouve sur les compteurs, mêmes plus anciens. Il existe plusieurs montages DIY, certains à base ESP et même sous Tasmota. Mais ça on en reparlera bientôt.

 

Home Assistant, Shelly & Energy

Il y a quelques avantages à choisir des modules Shelly plutôt que des chinoiseries. D'abord ces modules sont aux normes européennes, et ce n'est pas juste un adhésif CE posé par un mineur au fond d'une usine chinoise (pensez surtout aux assurances qui peuvent se montrer tatillonnes en cas de sinistre), le tarif est accessible et si vous avez une question (technique ou autre) le CEO de la boite vous répondra dans le fil Facebook de la marque ou par mail.

Une chose intéressante est également que beaucoup de ces modules remontent la consommation instantanée et cumulée. Je pensais naïvement que tous conservaient la consommation cumulée en cas de coupure secteur, mais, même si dixit le CEO c'était vaguement en projet en 2019, ce n'est toujours pas le cas et cette information sera perdue localement (sauf EM), bien qu'elle reste accessible sur le cloud Shelly via l'application idoine, mais impossible à récupérer via l'API.

Pour conserver cette information je me suis un peu torturé l'esprit depuis quelques jours en cherchant différentes solutions pour stocker et conserver ce chiffre, alors qu'en fait la solution était sous mes yeux et que je l'avait déjà utilisée quand j'avais déployé mon module de calcul des couts électrique globaux. La solution passe par l'intégration utility_meter: proposée de base par Home Assistant.

Utility Meter est une intégration qui va permettre de stocker le cumul d'une valeur sur une période donnée (hourlydailyweeklymonthlybimonthlyquarterly and yearly), ainsi que la même valeur sur la période n-1. Par exemple, si vous configurez en journalier,  à 13:45 vous pourrez afficher (ou utiliser) la valeur de consommation d'un compteur depuis minuit ainsi que celle à la même heure pour le jour précédent. Imaginez juste le code et les template qu'il aurait fallut imaginer sans cette intégration...

En ce qui me concerne, en prenant par exemple un Shelly 1PM qui pilote un convecteur, ce qui va m'intéresser est de connaitre la consommation cumulée en cours et celle pour le même jour l'an dernier.

Bien sur il est possible, avec un peu d'imagination et quelques lignes de code YAML, de stocker les années précédentes dans un input_number: ou même l'évolution dans une base de données et pour les plus maniaques d'utiliser Grafana pour afficher de beaux histogrammes. Même si ça ne changera probablement rien à la facture EdF, en partant du principe que si la domotique apporte un indéniable confort, de part le surcoût induit elle permet au final rarement réaliser de vraies économies.

En pratique

Dans cet exemple j'utilise l'intégration Shelly for Hass, mais il est toute à fait possible de faire la même chose avec d'autres types de modules, voire en intégrant les modules Shelly (ou autres) avec MQTT...

On crée nos entrées utility_meter: dans notre fichier de configuration : 

utility_meter:
  energy_total_yearly_ch_bureau:
    source: sensor.shelly_shplg_s_f8ccf83_total_consumption
    cycle: yearly
    
  energy_total_yearly_ch_cheminee:
    source: sensor.shelly_shsw_pm_68c63afaf521_total_consumption
    cycle: yearly
    
  energy_total_yearly_ch_salon:
    source: sensor.shelly_shsw_pm_68c63afaf658_total_consumption
    cycle: yearly
    
  energy_total_yearly_ch_cuisine:
    source: sensor.shelly_shsw_pm_68c63afaf1ca_total_consumption
    cycle: yearly

Ensuite on va pouvoir les utiliser directement pour les afficher, ici dans une carte ou j'ai utilisé le composant multiple-entity-row pour les besoins de l'affichage. Vous remarquerez l'utilisation de l'attribut last_period pour afficher l'année précédente.

entities:
  - entities:
      - attribute: last_period
        name: Année passée
        unit: kWh
    entity: sensor.energy_total_yearly_ch_cheminee
    name: Convecteur Cheminée
    secondary_info: last-changed
    show_state: true
    state_header: Année en cours
    type: 'custom:multiple-entity-row'
title: Consomation cumulée
type: entities

Bonus

Etant donné que j'avais dans un séjour ouvert trois convecteurs qui fonctionnent en même temps, j'ai créé deux sensor: pour regrouper ces informations afin de pouvoir afficher une seule ligne pour le séjour, un pour l'année en cours et un pour l'année précédente, qui de fait sera à zéro pour un moment. Attention, utility_meter: commence à compter au moment ou les entrées sont crées.

- platform: template
  sensors:
    energy_total_yearly_ch_sejour:
        friendly_name: "Total Séjour"
        unit_of_measurement: 'kWh'
        value_template: "{{ 
            (states('sensor.energy_total_yearly_ch_cheminee') | float) +
            (states('sensor.energy_total_yearly_ch_cuisinee') | float) +
            (states('sensor.energy_total_yearly_ch_salon') | float) }}"

- platform: template
  sensors:
    energy_total_yearly_ch_sejour_last_period:
        friendly_name: "Total Séjour (N-1)"
        unit_of_measurement: 'kWh'
        value_template: "{{ 
            (states('sensor.energy_total_yearly_ch_cheminee.attributes.last_period') | float) +
            (states('sensor.energy_total_yearly_ch_cuisinee.attributes.last_period') | float) +
            (states('sensor.energy_total_yearly_ch_salon.attributes.last_period') | float) }}"

 

 

Home Assistant & Visonic

Jadis, quand j'ai commencé à m'intéresser à la domotique, avec une Zibase, j'avais intégré les capteurs de mon système d'alarme Visonic Powermaster Pro. Ensuite sous Jeedom je les ai perdus, j'ai bien tenté avec un RFPLayer, qui dans l'absolu intégrait la techno ZiBase, de les retrouver, mais sans succès tant le plugin dédié et payant étant en dessous de tout. Un échec de plus pour Jeedom, peu importe que ce soit de leur faite ou celle de ZiBlue qui ne fournissait que peu d'informations, le résultat était négatif.

Sous Home Assistant j'ai bien essayé de me servir de la ZiBase pour récupérer ces informations, mais je n'ai pas trop insisté et j'ai fini par tout doubler avec des capteurs Xiaomi/Aqara.

Jusqu'à ce que je découvre la semaine dernière qu'il existait une intégration Visonic ! Mais pour ça il faut que ça communique. La centrale a des options que je n'ai pas et j'étais moyennement chaud pour commander une option RS232 à 80 € sur un site exotique. En lisant un peu j'ai fini par découvrir que cette option ne faisait qu'exposer physiquement le signal qui existe en TTL sur des broches accessibles. Alors j'ai fait des tests avec un câble RS232, USB/RS232 et j'ai même acheté un adaptateur Ethernet / RS232 (USR-TCP232-302) mais ça succès alors que certains disent y être parvenus, et même une pince pour sertir des connecteurs Dupont (l'enfer !), bref je me suis cassé le crane tout un week-end sans succès.

Reste une solution que je n'ai jamais explorée, utiliser un ESP_01 avec le firmware ESP-Link qui convertir les signaux TTL série afin de pouvoir les utiliser en Ethernet depuis l'intégration sous Home Assistant.

Communication

Alors d'abord il faut se procurer le module ESP NodeMCU. Ca doit pouvoir fonctionner avec d'autres ESP et d'autres firmwares mais je me suis contenté de suivre ce que j'ai trouvé. Ca vaut 1 €, c'est minuscule et ca peut tenir dans la centrale qui ainsi devient "WI-FI" !

Pour flasher le firmware ESP-Link il faut un adaptateur USB que je n'avais pas commandé pensant pouvoir le faire avec mon adaptateur USB éclaté. Certains ESP ont un bouton pour les passer en mode flashage, sur celui ci rien de tel, pas plus que sur l'adaptateur... C'est un peu le mystère laissé par les barbus, ne pas tout documenter sans quoi ce serait trop facile, ce genre de montage ça se mérite ! Bref, il faut shunter IO0 et GND avant d'insérer l'objet dans le port USB, ça permet de passer en mode programmation (je l'ai fait juste avec un câble Dupont...).

Maintenant il va falloir trouver un outil de flashage. Mais les barbus bossent sous Linux, et même s'il est possible de faire du Bash ou du Python sous Windows, ma machine ne s'est pas avérée très coopérative...

curl -L https://github.com/jeelabs/esp-link/releases/download/v2.2.3/esp-link-v2.2.3.tgz | \
    tar xzf -
cd esp-link-v2.2.3
esptool.py --port /dev/ttyUSB0 --baud 460800 write_flash -fs 4m -ff 40m \
    0x00000 boot_v1.5.bin \
    0x1000 user1.bin \
    0x7C000 esp_init_data_default.bin \
    0x7E000 blank.bin

Si la plupart des outils de flashage sous Windows fonctionnent, et même Tasmotizer, (Mathieu si tu me lis...), on va avoir besoin ici de flasher plusieurs fichiers .bin à des adresses particulières et le seul utilitaire qui a fonctionné est NodeMCU Firmware Programmer, qui selon les ESP utilisés permet de les fichiers flasher au bon endroit...

Une fois cette opération réussie (YES ! Ca m'a pris l'après midi...), on peu détacher l'ESP_01 de son support USB et aller le brancher dans la centrale. Il sera alimenté en 3.5 v par elle et servira d'interface TCP/Serie. Visonic a prévu des connecteurs dans la centrale afin d'y connecter des cartes optionnelles et couteuses, sauf que les signaux sont disponibles sur les connecteurs et que les cartes ne servent qu'à supporter des connecteurs... Des petits malins on fait un joli travail de recherche (voir les sources). Le connecteur qui nous intéresse est celui de gauche et en branchant un petit câble Dupont à 4 fils sur les 4 du haut à droite on sortira aisément GND TX RX et les 3.75 v nécessaires à l'alimentation de notre ESP.

Il ne reste plus qu'à connecter ça à notre ESP aux bons endroits, en inversant RX/TX et en faisant attention au connecteur d'alimentation car il n'y a pas de fusible...

Ensuite on se connecte en WI-FI sur son SSID (ESPxxx) et on renseigne le réseau WI-FI que l'on consacre aux IoT dans l'onglet WI-FI Station, il redémarre et on peu le pinguer... On pense à le mettre en réservation DHCP... Le seul réglage qui nous intéresse est la vitesse (9600 ou 38400 selon les modèles de centrales), et même si ce firmware permet de faire du MQTT et autres joyeusetées on désactive tout, il ne servira qu'à ça !

Intégration à Home Assistant

Cette intégration j'ai du la lancer 50 fois, mais quand on a la bonne communication ça fonctionne du premier coup. Elle permet beaucoup de choses, mais le mode standard qui me permet de voir et utiliser mes capteurs est suffisant. Je m'en contenterais car dans mes bricolages j'ai perdu le code installateur de la centrale ce qui va me limiter à l'avenir ! (code impossible à reseter). EDIT : Je viens d'apprendre qu'on peut justement le récupérer, grâce à une fonction non documentée de cette intégration...

On installe donc l'intégration Visonic, encore un excellent travail d'un passionné, et on renseigne l'IP et le port (23) de notre ESP. Et c'est tout, comme par magie les capteurs remontent ainsi que le panneau de commande. Il sera ainsi possible d'armer et désarmer la centrale depuis Home Assistant (Géoloc, présence pour l'armement et tag NFC pour le désarmement dans mon cas) et de savoir quel capteur à déclenché l'alarme dans une notification (Slack, TG ou SMS), mais aussi de conserver un log (CSV et/ou XML).

Ce qui m'embête c'est que je me retrouve avec d'un coté mes capteurs Xiaomi / Aqara qui me servaient à l'alarme HA, à couper le chauffage quand on ouvre les fenêtre ou allumer une lampe en cas de passage, et mes capteurs Visonic qui peuvent faire la même chose... Bref, j'aurais su avant je ne me serait pas lâché sur Ali Express...

Sources

J'ai écrit ça rapidement, mais voici mes sources qui contiennent pas mal d'informations pour qui voudra se lancer dans l'expérience

 

Unifi Dream Machine Pro

Chez les afficionados de la marque on a généralement tous commencé par un AP WI-FI. Et puis comme ça fonctionnait bien et que c'était beau on s'est laissé aller pour un USG, et là c'était beau, mais pas exempt de bugs et surtout limité en CPU pour exploiter une fibre ou DPI/IPS. Il y a bien eu l'USG Pro, pas vraiment beaucoup plus puissant. Sur tous ces modèles le VPN n'a jamais été le point fort et quant à faire de la publication il n'y a rien d'autre qu'une possible translation de ports entrants comme sur un vulgaire routeur grand public, si cela pouvais se comprendre sur les modèles précédents, on aurait aimé un reverse proxy sur la machine censée nous faire rêver !


(source Unifi)

Mais il n'en est rien, il faut considérer l'UDM Pro, et c'est son positionnement marketing, comme un routeur d'accès avec des services (Contrôleur Unifi, Unifi Protect, contrôle d'accès, téléphonie IP, etc..). Si l'on souhaite publier des services on regardera plutôt du coté de pfsense ou autres Appliance qui font ça très bien. Et si on veut faire du VPN,  ce qui est par contre dans la cible du produit, ce sera IPSEC ou OpenVPN. Zerotier ayant été porté sur la gamme Edge, il y a des chances que quelqu'un fasse le portage sur l'UDM Pro, voire qu'Unifi le fasse, à moins qu'ils ne se laissent tenter par WireGuard...

A 319 € (HT) l'UDM est un produit intéressant qui combine donc plusieurs fonctions : 

  • un USG performant avec fonctionnalités de firewall avancées (IPS/IDS, DPI)
  • un switch 8-port Gigabit et un port 10G SFP+, un port WAN Gigabit et un second port WAN en 10G SFP+ (de quoi y raccorder les nouveaux produits en 2.5 GB et 10 GB actuellement en Early accès et profiter des offre fibre en 2.5 GB ou 10 GB proposées par certains FAI).
  • un contrôleur UniFi (= CloudKey ou CloudKey Gen2+).
  • un NVR UniFi Video avec emplacement disque dur 3.5″ ou 2.5".
  • d'autres contrôleurs à venir (contrôle d'accès, téléphonie IP, et certainement quelques autres projets dans les cartons...).
  • et enfin comme tous les Gen2 de la marque on est en présence d'un petit écran de contrôle en face avant. Petit gadget pour doigts de fée !

Si le contrôleur Unifi intégré pourrait très bien trouver sa place ailleurs (VM, Cloud, ...), l'enregistreur vidéo (Unifi Protect), qui est identique, mais plus puissant que celui que l'on trouve sur le CloudKey 2+, constitue un vrai plus si on veut gérer un grand nombre de caméras et stocker jusque à 14 TB de vidéos de surveillance. A noter qu'il existe chez Unifi un autre NVR plus puissant avec le support de 4 disques.

Le NVR

Ca c'était le bla bla marketing annoncé. Dans la pratique Unifi Protect sur l'UDM Pro me semble bien bogué pour un produit sorti il y plus de six mois. Ca commence avec le disque dur, quelque soit le modèle installé parfois il le voit, parfois pas, et quand il le voit il ne l'exploite pas (impossibilité d'enregistrer). Certains conseillent de le retirer et de le formater en ext4, pas mieux, de juste supprimer les partitions, là il est visible mais non exploitable. Pas très normal qu'on ne puisse pas lancer l'initialisation/formatage depuis l'interface. Et je passe sur les paramètres des caméras qui sont pris en compte depuis l'application mobile mais impossible depuis le portail web qui lui répond que la caméra n'est pas reconnue, alors qu'elle l'est bien sur... A cette heure je regrette ma CloudKey 2+ !

Le routeur

Le routeur d'accès qui lui remplacera l'USG reste à apprécier à l'usage, Ca remplace mais ça reste un USG dont je ne vais pas reprendre le détail ici, un une partie qui mériterais de la part d'Unifi quelques évolutions, avec notamment l'intégration à l'interface de tout ce qui n'apparait pas mais reste faisable en CLI.

2 ports WAN, mais un seul en 10 G !

A noter que le WAN1 qui est en 1 GB est toujours le port principal WAN et que si on souhaite faire du failover on le fera avec le WAN 2 qui lui est en 10 GB (SFP+) ou en 1 GB en utilisant un adaptateur UF-RJ45-1G. C'est d'autant plus bête qu'en utilisation normale on peut imagine une grosse fibre sur le WAN principal et un xDSL en secours. Ca reste du soft, et on peut imaginer une évolution du firmware, et pourquoi ne pas banaliser tous les ports en WAN/LAN comme le fait Cisco depuis plus de 10 ans sur des produits SMB de la gamme RV.

Dans tous les cas, sur le papier, on reste sur de l'agrégation ou du failover utilisable en sortie, et pour l'instant c'est failover only (La seule solution intégrale d'agrégation via un tunnel restant l'OTB d'OVH ou sa version open source openMPTCP).

Quand au WI-FI contrairement à l'UDM, l'UDM Pro qui se place dans un rack n'intègre logiquement pas d'AP. Alors on est tout de même en droit de se demander pourquoi sur un produit qui est censé gérer des AP et des caméras en POE, on ne trouve aucun ports POE ? Je pense simplement qu'à la conception la question a bien du se poser, le marketing l'a emporté en argumentant que cela ferait vendre des commutateurs POE, produits sur lesquels la marge est certainement bien plus importante. C'est dommage car avec quelques ports POE l'UDM Pro aurait été presque parfait ! Business is business !

Un firmware intégré...

Contrairement aux habitudes prises avec Unifi, ici le firmware intègre tout, le firmware de la machine de base proprement dite (USG), le contrôleur Unfi Network, le contrôleur Unifi Protect et les autres applications... Si la bonne idée est de simplifier, on va voir que dans la pratique ce n'est pas si simple tant les versions sont évolutives chez eux...

Coïncidence, mon UDM Pro est arrivé le lendemain du jour ou j'ai mis à jour (par erreur) ma CloudKey 2+ avec le contrôleur avec 6.0.20. Mal m'en a pris car cette version, tout comme la suivante en 6.0.22 est tellement buggées qu'on peut aisément penser qu'elle a été lâchée en release par erreur (un stagiaire ?). Problème, la 6.0.x n'existe pas sur l'UDM Pro qui est en firmware 1.8 qui intègre le contrôleur en 5.x. Dès lors impossible de migrer une installation en 6.x vers du 5.x ! (il ne s'agit pas vraiment d'un process de migration mais une simple opération de backup/restaure, il faut donc que la source ait un niveau de release inférieur ou égal au contrôleur de destination).

Alors j'ai cherché, j'ai fini par installer la 1.8.1 RC3 qui n'apporte hélas pas de contrôleur en 6.x ... et pour finalement découvrir qu'il était possible de mettre à jour le contrôleur d'UDM Pro en SSH. Et pourquoi pas avec un bouton upload ? On a parfois l'impression qu'il y a chez Unifi pas mal d'ingés de l'ancien monde, ceux pour qui le CLI est et reste la seule option possible... Ce qui n'est pas très logique pour un constructeur qui se démarque avant tout par ses magnifiques interfaces !

ssh udm ...
unifi-os shell
cd /tmp
curl -o "unifi_sysvinit_all.deb" https://dl.ui.com/unifi/x.xx.xx_version/unifi_sysvinit_all.deb
dpkg -i unifi_sysvinit_all.deb 
rm unifi_sysvinit_all.deb 

Et comme je n'ai pas reçu ce produit du service de presse pour le tester, mais que je l'ai acheté pour l'utiliser, me voilà donc en principe dans la possibilité de migrer. Je fait un export du contrôleur et un export du NVR depuis la CK 2+ (je ne me pose pas la question d'exporter les vidéos de la CK 2+, mais il parait que c'est possible...). Ensuite je débranche l'USG et la CK 2+, c'est important. A partir de la il me suffira en principe d'importer le backup du contrôleur sur l'UDM Pro et ensuite le backup du NVR.

Dans la pratique c'est un peu plus compliqué. Si l'importation se passe bien le redémarrage annoncé ne s'opère pas. Je le fais manuellement au bout d'une heure. Mais au retour je ne peux me connecter localement, ni sur l'ancienne l'IP (192.168.1.1), ni sur l'IP de configuration importée (192.168.210.1). Par contre je peux le faire à distance (à noter que c'est un nouveau portail d'administration). Et là en fouillant je constate deux choses :

  • Le port 11 (SFP) qui assure la liaison avec mon USW-48 a perdu sa configuration en 1 GB FDX (et non il n'est pas auto sense...)
  • Que si l'IP LAN a bien été importée dans la configuration, c'est toujours l'ancienne IP qui répond, et de fait le système ne voit pas les autres équipements importés (SW, AP).

Réactiver le port SFP en FDX est facile, pour que l'IP LAN soit bien prise en compte j'ai finalement rentré l'ancienne à la place de la nouvelle, appliqué la configuration, et ensuite remis la nouvelle, et oh merveille ça fonctionne. Oh merveille mon cul, car c'est vraiment n'importe quoi.

A ce stade tout semble fonctionner, bien que dans cette version non finalisée (6.0.22) certaines choses sont à faire dans la nouvelle admin (VPN) tandis que pour d'autres actions il faudra revenir à l'ancienne interface. beta bug beta bug ! Enfin, tout sauf que si le WAN2 sait bien fonctionner en failover, contrairement à l'USG il est ici impossible de la basculer en agrégation (pas de réponse à ce sujet pour l'instant).

Il y a également depuis le 6.0.x des équipements WI-FI qui décrochent. C'est par exemple systématique sur les ampoules Xiaomi/Yeelight, j'ai tout retourner sans trouver de contournement. Et pour mémoire, quand on migre d'une 5.x vers une 6.0.20 il y a un Vlan only network - 0 qui se crée, je pense que c'est lié à la nouvelle façon de gérer le WI-FI Guest, en attendant il empêche toute connexion WIFI normale et il faut donc l'effacer ou le le changer d'ID (en 100 par exemple). Sur le 6.0 le WI-FI est géré différemment et on peu créer plus de 4 SSID, ce qui est par exemple plus souple pour les différencier en 2 ou 5 Ghz. et en isoler certains (IoT par exemple).

Domotique

Pour information les intégrations Unifi et Unifi Protect que l'on utilise dans Home Assistant fonctionnent et reconnaissent bien l'UDM. Petit hic il faut les réinstaller car je n'ai pas trouvé (pas trop cherché non plus) la façon de changer l'IP du contrôleur et du NVR (dans HA). Le résultat est que certaine entités peuvent changer de nom et qu'il faudra s'adapter.

Conclusion

Par la force des choses je me retrouve :

  • en prod avec du matériel qui tourne intégralement sur des versions beta. Une pratique à éviter.
  • avec un enregistreur qui n'enregistre plus rien...
  • des équipements WI-FI qui décrochent.
  • avec une foule de bugs dont une agrégation de ports inopérante.

Vous l'aurez compris, la machine à rêver ne m'a pas fait rêver mais perdre beaucoup de temps et me retrouver dans une situation très instable !

  • EDIT 22/09/2020 14:00 : la v6.0.23 du contrôleur est sortie et ça règle bien plus de choses qu'annoncé. Dont mes déconnections avec les ampoules Xiaomi/Yeelight. En fait non, mais ça tient quelques heures au lieu de 5 minutes...
  • EDIT 22/09/2020 17:30 : S'agissant de l'enregistrement sur détection de présence (Protect) et de l'enregistrement il semblerait qu'un paramètre n'ait pas été pris en compte lors de la migration ou qu'il soit nouveau (sur chaque caméra, Recording/Motion Events/Motion Algorithm), il faut faire un choix et aucun des deux n'était sélectionné. Dès lors qu'un disque dur est bien reconnu on a donc bien les enregistrements.
  • EDIT 23/09/2020 04:37 : Il est possible d'intervertir WAN1/WAN2 afin que WAN1 (le principal) profite de l'interface 10 GB sur WAN1 (et sans passer par SSH). Par contre pour l'instant seul le support du mode Failover, pour le Load Balancing (supporté sur l'USG) il faudra repasser plus tard.
  • EDIT 23/09/2020 18:22 : En parlant de plus tard, le SNMP, un peu la base sur un routeur, est caché (New Seetings + search snmp), mais pour autant il ne fonctionne pas. Il parait que apt-get ... etc... On se marre !
  • EDIT 23/09/2020 19:30 : Passage de la 6.0.23 en release et sortie de la 6.0.24 en beta. Ca turbine chez Uniquiti, il faut dire que ça grogne partout ! Nouveaux firmwares UAP/USW. Nouvelles déconnexions sur les ampoules Xiaomi.
  • EDIT 29/09/2020 17:17 : S'agissant des ampoules Xiaomi, j'ai essayé tous les paramètres possibles et imaginable ainsi que les version beta de firmware sans obtenir de résultat. J'en conclu que quelque chose a vraiment changé dans cette version qui a plus une allure de beta que de release. J'ai donc honteusement ressorti un vieil AP Netgear...
  •  

J'espère pouvoir échanger avec Unifi et qu'ils sauront m'apporter des réponse satisfaisantes à tous ces problèmes. Je mettrais bien sur à jour cet article énervé en fonction de.

Sources

 

Home Assistant & BLE : Présence

Il y a quelques temps je vous avait déjà parlé de BLE (Bluetooth Low Energy) pour remonter des sondes de température Xiaomi. Le composant utilisé fonctionne bien et ça évolue, il n'y a rien à redire, sinon que ça ne gère pas la présence. Hors la notion de présence est importante en domotique.

Il y a plusieurs façons de gérer la présence dans Home Assistant

  • En géolocalisation en utilisant les API Google. Ça fonctionne bien au point de faire peur, mais ce n'est pas suffisamment réaction pour certaines actions. Par exemple si je veux ouvrir le portail, allumer des lampes et désactiver l'alarme lors de mon arrivée, il y a des chances que j'attende 5 minutes face au portail... Et que si j'ouvre le portail avec une télécommande l'alarme soit encore active lorsque je rentre dans la maison. C’est donc inutilisable pour cet usage.
  • Une application genre OwnTrack n'est pas beaucoup plus performante et consomme plus de batterie.
  • Un TAG RFID, ça fait le job mais il y a une interaction physique. Donc OK pour l'alarme, mais pas pour le portail...
  • Le WI-FI, en s’appuyant sur l'intégration Unifi (il y en a d'autres), c’est pas mal mais il me faudrait un AP à l'extérieur pour un meilleur résultat.
  • Un gardien ou un majordome serait idéal, mais je n'en ai pas les moyens !
  • J'ai pensé au ZigBee, mais la portée est trop courte et il me faudrait déporter un répéteur.
  • Il reste donc la voie du BLE que j'avais laissé de coté car l'intégration de base n'est pas à la hauteur de ce que j'avais avec un des meilleurs plugin sous Jeedom.

Pour palier à l'intégration BLE d'origine sous HA on dispose à ce jour de deux projets bien aboutis qui peuvent fonctionner soit de façon autonome sur un RPI, soit sous forme d'addon à installer directement dans Home Assistant. Dans les deux cas ils communiqueront avec HA en MQTT, et c'est un plus indéniable ! En ce qui me concerne j'ai testé les addon, mais un RPI0 indépendant sera idéal si on veut créer un réseau avec le second projet.

Monitor

Bluetooth Presence Monitor s'installe en ajoutant son dépôt dans le gestionnaire d'addon ou en partant du dépôt original si on veut l'installer à part. La configuration est simple :

mqtt:
  broker: 192.168.210.44
  port: 1883
  username: user
  password: password
  topic_root: presence
  publisher: ''
known:
  beacons:
    - 'F8:DE:32:B1:07:3D Tile'
  static:
    - '94:65:1D:D1:AD:96 5T'
    - '50:77:05:F6:0F:2F Note 9'
blacklist:
  - '58:2D:34:10:1D:4F'
  - '58:2D:34:10:12:77'
extra_arguments: '-a -x -b -tdr -r'

Par contre il faudra prendre soin d'aller régler le port BT dans le fichier /share/presence-monitor/behavior_preferences afin que cela ne rentre pas en confit avec un autre port (à ce niveau l'O/S ne gère pas le partage des ports comme celà pourrait être le cas sous Windows ou MacOS par exemple). Cela veut dire que si on a déjà une intégration qui utilise un port BT il faudra un dongle USB BT. Dans mon cas j'utilise une clé SENA TD100 que l'on trouve encore ici. C'est dans ce même fichier de configuration que l'on pourra ajuster tous les paramètres, fichier que l'on aurait aimé accessible depuis l'addon bien sur...

PREF_HCI_DEVICE=hci1

A partir de là on lance l'addon et on observe le log pour ajuster la configuration afin de choisir ce qui sera notifié au broker MQTT. Ensuite il faut créer un sensor: qui aura pour valeur le pourcentage d'éloignement ainsi qu'une très utile notion de départ / arrivée.

  - platform: mqtt
    state_topic: 'presence/homeassistant/tile'
    value_template: '{{ value_json.confidence }}'
    unit_of_measurement: '%'
    name: 'Tile BLE'
    icon: mdi:bluetooth

On va également créer un device_tracker: qui lui nous fournira un device tracker que l'on retrouvera comme d'habitude dans le fichier known_devices.yaml

  - platform: mqtt
    devices:
      TileBLE: 'presence/homeassistant/tile/device_tracker'
      name: "Tile BLE"
      icon: mdi:bluetooth

A ce stade ça fonctionne avec une prise en compte des équipements perfectibles, mais je n'ai pas creusé les paramètres avancés car entre temps je suis tombé sur Room Assistant. Par ailleurs mon TAG Tile ne semble pas être le meilleur pour cet usage et j'ai commandé un Nut 3.

Room Assistant

Room Assistant est à ce jour ce que j'ai trouvé de plus complet et de plus prometteur. L'installation de l'addon se fait depuis ce dépôt (ou ici si on installe à part) et on se concentrera sur le fichier de configuration, un lancement à vide nous permettant de repérer les adresses MAC des différents équipements.

Le gros avantage de Room Assistant est qu'il offre la possibilité de fonctionner en réseau, ce que l'on connaissait avec le plugin BLEA de Jeedom. Il sera ainsi possible de localiser les habitant d'un logement à la pièce près en se basant sur le signal BT/BLE. Je n'ai pour l'instant pas exploité cette possibilité, mon besoin étant le départ / arrivé de mes utilisateurs.

global:
  instanceName: canaletto_ble
  integrations:
    - homeAssistant
    - bluetoothLowEnergy
    - bluetoothClassic
    - xiaomiMi
homeAssistant:
  mqttUrl: 'mqtt://192.168.210.44:1883'
  mqttOptions:
    username: user
    password: password
bluetoothClassic:
  minRssi: '-20'
  hciDeviceId: 1
  addresses:
    - '94:65:2D:D4:XX:77'  # Mon mobile
bluetoothLowEnergy:
  hciDeviceId: 0
  onlyIbeacon: true
  timeout: 30  # Utile pour éviter les faux départs sur certains tags
  whitelist:
    - f8dedfgh73d  # Mon Tag Tile
  tagOverrides:
    f8dedfgh73d:
      name: Tile
xiaomiMi:
  hciDeviceId: 0
  sensors:
    - name: Clear Cuisine  # Xiaomi CGG1
      address: 582d3dfgsd6d
    - name: Clear SdB  # Xiaomi CGG1
      address: 582d3dgf3286
    - name: Clear Exterieur  # Xiaomi LYWSDCGQ
      address: 4c6dfgd1db75
    - name: Clear Square  # Xiaomi LYWSD02
      address: 3fdfg88270ca
    - name: Clear Clock  # Xiaomi CGD1
      address: 58sdfgsd3292
      bindKey: cc0d9dfgdsfgsdf4e7f495d27eacf5250e2e8
entities:
  behaviors:
    ble-f8desdb1073d-tracker:
      debounce:
        wait: 10.75
        maxWait: 20

On passe rapidement sur la classique config MQTT pour noter que si l'intégration bluetoothLowEnergy et xiaomiMi peuvent partager le même port BT (BLE dans les deux cas), ce port devra être différent pour du bluetoothClassic. Le développeur travaille au partage de port mais ce n'est pas pour l'instant possible.

L'intégration, la création, dans Home Assistant des sensors: est automatique via MQTT (présence, température, etc..), par contre il faudra manuellement créer les device_tracker: si on souhaite les exploiter.

  - platform: mqtt # Room-Assistant
    devices:
      ra_tile: 'room-assistant/device_tracker/ble-f8de32b1073d-tracker/state'
      name: "Tile BLE"
      icon: mdi:bluetooth
    payload_home: 'true'
    payload_not_home: 'false'
    source_type: bluetooth   

Ensuite il va falloir exploiter et pour le debug je me sert de Slack pour faire un log dynamique. On commence par deux automations pour simuler un départ et une arrivée (je me contente d'enlever la pile du Tile ou de le coller dans le micro onde... Je me sert ici du device_tracker:

- alias: Alarm Test Tile leave
  trigger:
    platform: state
    entity_id: device_tracker.ra_tile
    from: 'home'
    to: 'not_home'
  action:
  - service: notify.slack_hass_canaletto
    data:
      message: "{{now().strftime('%d/%m/%Y, %H:%M:%S')}} > TEST TILE Leave" 

- alias: Alarm Test Tile enter
  trigger:
    platform: state
    entity_id: device_tracker.ra_tile
    from: 'not_home'
    to: 'home'
  action:
  - service: notify.slack_hass_canaletto
    data:
      message: "{{now().strftime('%d/%m/%Y, %H:%M:%S')}} > TEST TILE Return" 

Mais, car il y a un mais, j'ai remarqué que visuellement mes deux icônes ne changeait pas d'état à la même vitesse, le sensor: étant plus rapide. Je fais donc une seconde paire d'automation avec lui...

- alias: Alarm Test Tile leave device
  trigger:
    platform: state
    entity_id: sensor.tile_room_presence
    from: 'canaletto_ble'
    to: 'not_home'

  action:
  - service: notify.slack_hass_canaletto
    data:
      message: "{{now().strftime('%d/%m/%Y, %H:%M:%S')}} > TEST TILE Leave Sensor" 

- alias: Alarm Test Tile enter device
  trigger:
    platform: state
    entity_id: sensor.tile_room_presence
    from: 'not_home'
    to: 'canaletto_ble'
  action:
  - service: notify.slack_hass_canaletto
    data:
      message: "{{now().strftime('%d/%m/%Y, %H:%M:%S')}} > TEST TILE Return Sensor" 

Et là on a une vraie surprise dans les résultats car on gagne 10 secondes ! Et 10 secondes sur une arrivée c'est hyper important car c'est à peu près le temps que je dois mettre pour aller du portail à la porte d'entrée...

14/09/2020, 23:12:41 > TEST TILE Leave using sensor:
14/09/2020, 23:12:52 > TEST TILE Leave using device_tracker:
14/09/2020, 23:13:01 > TEST TILE Return using sensor:
14/09/2020, 23:13:12 > TEST TILE Return using device_tracker:

Voilà, il va maintenant falloir faire des tests en live, l'idéal serait que le tag puisse être détecté quand je me gare devant le portail, mais pour ça il me faudra que j’équipe la clé SENA avec une antenne plus performante. Je trouve que les délais d'Accroche / Décroche des mobiles sont excellents et j'attend mon Nut pour d'autres tests.

Le support des capteurs Xiaomi est récent et pour l'instant l'information concernant le niveau de batterie n'est pas disponible pour tous contrairement à MiTemp. Mais ça devrait venir. Ce qui est amusant, sinon intéressant, c'est que dans cette intégration un capteur de température Xiaomi peut devenir un TAG et être vu par HA en tant que tel... Mon Tile ne fonctionnant pas très bien, j'ai donc pensé à laisser un CGG1 dans ma voiture...

Voilà pour ces petits tests, je suis bien sur disponible pour échanger sur TG ou ici dans les commentaires. N'hésitez pas à partager vos expériences afin que je puisse au besoin mettre à jour cet article.

EDIT : Je n'ai pas encore eu le temps de tester mais les informations trouvées ici me semblent pertinentes.

EDIT 2 : Pour  la géo loc l'application Life 360 semble ce qui se fait de mieux, il existe une intégration à HA. A combiner avec le reste.

Et en WI-FI

Si gérer la présence en Bluetooth peut sembler évidente, à l'usage on s'aperçoit que le BT des mobiles décroche trop souvent, que celui des tags BLE n'est pas assez rapide et surtout que même avec une clé Sena et une antenne la portée est trop réduite. Finalement le WI-FI reste une très bonne solution, à condition d'avoir un AP gérable (Unifi avec intégration Unifi ou Unifi AP qui est légèrement plus rapide) et d'autres marques reconnues, Netgear par exemple. Ce qui est intéressant ici c'est que dès que l'AP voit le mobile (sa MAC, sans pour autant que le signal soit suffisant pour un appairage et qu'il ait une IP) HA est informé de la présence du device et peut ainsi gérer des automatismes. Le décrochage est long ce qui garantie l'absence de faux positifs mais l'accrochage est lui très rapide.

Sources

 

 

Home Assistant IR, AC & More...

Pour piloter un climatiseur avec Home Assistant il existe plusieurs options, mais vu qu'il n'existe pas de protocole unifié (à par peut être KNX que l'on oublie pour des questions de coûts), ça va bien souvent se terminer en IR, là ou une option MQTT sur les interfaces WI-FI des constructeurs aurait été une bénédiction. En dehors de Dalkin qui dispose d'une intégration et Xiaomi (non importé), ces interfaces sont bien sur propriétaires et fermées.

Alors on se rabat sur l'infrarouge, ce qui n'est pas très sexy en 2020 ! D'ailleurs si vous voulez juste piloter une clim avec une application, plutôt que de payer cher une option WIFI du constructeur, pour 80/90 € offrez vous simplement un Tado ou un Sensibo, ça fera le job en mieux et ce sera compatible Alexa et Google Home, avec des intégrations Home Assistant (Tado | Sensibo) à la clé. Sauf que c’est du cloud et que je veux un pilotage local.

On va donc partir sur un Broadlink qui dispose d'une intégration. A la base ce gadget permet de piloter n’importe quel appareil IR depuis une application mobile. Ici on va faire la même chose, mais de puis Home Assistant, et on va voir qu'il existe plusieurs façons de faire, et accessoirement que j'ai perdu bien du temps en ne trouvant pas la seconde option tout de suite...

Intégration du Broadlink à Home Assistant

Ça c'est la première chose à faire dans tous les cas, sans perdre de vue que votre Broadlink sera sur l'application ou sur Home Assistant, pas les deux. Il est toutefois intéressant de l'ajouter une fois à l'application pour récupérer son IP et son adresse Mac.

  1. On supprime le Broadlink de l'application mobile.
  2. Sans le débrancher on lui fait un reset en appuyant 6 secondes avec un trombone.
  3. On ajoute le Broadlink au réseau avec l'application, mais sans le connecter au cloud Broadlink, pas maintenant, pas plus tard. On sort de l'application et on l'oublie.

Ensuite on ajoute ces quelques lignes au fichier configuration.yaml en reportant les infos précédament récupérées et on redémarre HA. Idéalement on place une réservation DHCP sur cette IP.

remote:
  - platform: broadlink
    name: rm4_mini
    type: rm4c_mini  # Ça c'est très important....
    host: 192.168.210.132
    mac: '24:AF:A2:30:0D:E2'

A partir de là on a deux possibilités. La première va consister à apprendre les codes IR et à les restituer. Pour les apprendre on va faire un petit script et se laisser guider par les notifications de Home Assistant pour presser sur les touches idoines au bon moment...

learn_tv_commands:
  alias: Apprentissage IR
  sequence:
  - data:
      command:
      - turn on
      - turn off
      - volume up
      - volume down
      - chanel up
      - chanel down
      device: television_sam
      entity_id: remote.sam
    entity_id: remote.rm4_mini
    service: remote.learn_command

Et on va se retrouver avec les fichier /config/.storage/broadlink_remote_24dfa2300de2_codes qui va contenir nos codes IR, fichier dans lequel il nous suffira d'aller récupérer les bons codes.

{
    "data": {
        "television_sam": {
            "chanel down": "JgDSAJOUEjcTNxQ1ExIUERMSExITERQ2FDYTNhMSExITEhMSFBETERQRExITEhM2FBETEhMSFDYUNRM3FDYTEhM2EzcTNhQABgKWkhQ2EzcUNRQRExITEhMSFBEUNRM3EzYUERMSFBEUERQRExITERQRExIUNhMSFBEUEBQ2EzYUNhM3FBETNhM3EzYVAAYBlpIUNhQ2FDUTEhQRFBEUERMRFDYUNhM2FBEUERQRExIUERQQFBEUERMSFDUVEBQRExIUNhQ1FDYUNhQQFDYUNhQ1FQANBQAAAAA=",
            "chanel up": "JgAYAZSTEzcTNhM3ExIUERMRFBETEhQ2FDUUNhQRExITERUQFBETEhQ2FBEUEBQ2ExIUERQRFDUTEhQ2FDUUERQ2FDUUNhQABgOUkxQ2EzcUNRMSExIUERQRFBAUNhQ2FDUUERQRFBEUERQRFBAUNhQRExIUNRQRFBETEhM2FRAVNRM3FBETNhQ2FDUVAAYClZIVNRQ2FDUVEBQRFBEUERMSFDUUNhQ2FBAVEBMSFBEUERQRFDUUERQRFDYTERUQFBEUNhMSFDUUNhMSFDUUNhM3FAAGApWTFDUUNhM3FBAUERQRFBETEhQ1FTUUNhQRExEVEBQRFBETEhQ1FRAUERQ2FBETERQREzcUERQ1FDYUERQ1FDYUNhQADQUAAAAAAAAAAAAAAAAAAA==",
            "turn off": "JgBGAJGVEzcTNhQ2ERQTEhMSExEUERM3EzcTNhMSExITEhEUExEUERM3ExITEhMREhMTEhMSEzYUERQ2ETkTNhQ2EjgTNhQADQU=",
            "turn on": "JgCMAJWTEzYTNhQ2FBETEhMSExEUERQ2EzYUNhQRFBETEhMSExEUERQ2ExITEhMRFBEUERQREzYUERQ2FDYTNhQ2FDYTNhQABgOVkhQ2FDYTNhQRFBEUERMSExITNhQ2EzYUERQRFBEUERMSExITNhQRFBETEhMSExEUERQ2ExITNhQ2FDYTNhQ2FDYTAA0FAAAAAAAAAAAAAA==",
            "volume down": "JgDSAJSTEzYTNxM3ExIRExMSExITEhM3ETgSOBMSExITERQRExITNxM2ExITNxEUExISEhMSExITEhM3ERMTNxM3EzYSOBEABgSWkxE5ETgTNxEUExITEhISEhMTNxM2EzcTEhMSExIRExMSEzcTNhITEzcRFBMSExIRExMSExITNxEUEjcTNxE4EzcTAAYDlZMTNxM2EzcTEhMSExITERQREzcTNxI3ExITEhMSExITERQ2EzcTEhM2ExITEhMSExETEhMSEzcTEhM2EzcTNxM2EwANBQAAAAA=",
            "volume up": "JgDSAJKVETgSOBE5ERQRExITEhMRFBE5ETgSOBEUERQRExITEhMRORE4EjgRFBEUERQRExITEhMRFBEUETgSOBE5ETgSOBIABgSVkxQ2EzYUNhMSExITERQRFBEUNhM2FDYUERMSExITERQRFDYTNhQ2FBETEhMSExITERQRFBETEhM2FDYUNhM2FDYUAAYClJQTNxM2FDYTEhITEhMSEhMSEzcSNxM3ExISExEUEhISExM3EjgROBITERQRFBEUERMSExITEhMROBI4EjgROBI4EQANBQAAAAA="
        }
    },
    "key": "broadlink_remote_24aca7a1dce2_codes",
    "version": 1
}

Ensuite on va créer un switch qui pourra d'ailleurs en contenir plusieurs... Et avec lesquels ont pourra interagir depuis des automation, scripts ou l'interface Lovelace...

- platform: broadlink
  host: 192.168.210.132
  mac: '24:AF:A2:30:0D:E2'
  type: rm4c_mini  # Toujours aussi important !
  timeout: 15
  switches:
    tv_on:
      friendly_name: "TV Power"
      command_on: 'JgCMAJWTEzYTNhQ2FBETEhMSExEUERQ2EzYUNhQRFBETEhMSExEUERQ2ExITEhMRFBEUERQREzYUERQ2FDYTNhQ2FDYTNhQABgOVkhQ2FDYTNhQRFBEUERMSExITNhQ2EzYUERQRFBEUERMSExITNhQRFBETEhMSExEUERQ2ExITNhQ2FDYTNhQ2FDYTAA0FAAAAAAAAAAAAAA=='
      command_off: 'JgDSAJKUFDYSOBI3ExITEhITEhMSExI2FDcSNxMSExITEhITEhMSExI3ExISExITEhITEhMSEjgSExI3EzcSOBI3EzcSNxMABgOVkxQ2EzcSOBMRFBETEhITExITNhQ2EjcUERQRFBETEhITExITNhMSExITEhMSExEUERM3ExISNxQ2EzcTNhQ2EzcTAAYClZQTNhQ2EzcTERQRFBETEhMSEzYUNhM3EhMSEhMSFBETEhITEjcTEhMSEhMSExITEhITNxITEjgSNxM3EjcTNxM3EgANBQAAAAA='

Ça c'était la version manuelle, c’est pratique car ça permet d'associer n’importe quel appareil piloté par une télécommande IR. Par contre c'est fastidieux et j'ai passé mon après-midi à me dire qu'il était impossible que quelqu'un n'ai pas fait mieux, à savoir une intégration ou je n'aurais qu'à choisir la référence de mon climatiseur pour le commander avec une carte Climate. Et ça existe !

SmarIR

SmartIR s'appuie sur le Broadlink, ou d'autres interfaces IR, qu'il s'agisse de Xiaomi, d'un ESP DIY ou d'un objet en MQTT. Pour le configurer il nous faut avoir intégré notre interface à HA, ici le Broadlink, et installer le composant depuis HACS.

Pour activer cette intégration on ajoute une entrée dans configuration.yaml :

smartir:

Une entrée dans switch.yaml :

- platform: broadlink
  host: 192.168.210.132
  mac: '24:AF:A2:30:0D:E2'
  type: rm4c_mini  # Toujours aussi important !

Et enfin une dernière dans climate.yaml ou l'on n'oubliera pas de reporter le bon code IR : 

- platform: smartir
  name: Office AC
  unique_id: office_ac
  device_code: 1260  # Ici le code IR pour les climatiseurs Toshiba
  controller_data: 192.168.210.132
  temperature_sensor: sensor.temperature  # Ici on peut associer un capteur de température externe
  humidity_sensor: sensor.humidity  # Ici on peut associer un capteur d'hygrométrie externe
  power_sensor: binary_sensor.ac_power

Un petit redémarrage et on est prêt à piloter notre climatiseur comme on le ferait pour n'importe quel thermostat, sauf qu'ici on dispose de toutes les commandes utiles (mixte, chauffage, refroidissement, de-humidification, ventilation) propre au modèle choisit (on ne voit pas

Mon projet portait sur la climatisation, mais avec SmartIR il est également possible de piloter des ventilateurs ou du matériel Audio / Vidéo, pourquoi pas votre magnétoscope VHS ! Et ce qui ne sera pas possible avec SmartIR le sera en mode manuel.

EDIT HA 0.115 : Broadlink est maintenant intégré à HA, donc on vire ce qui est dans configuration.yaml et switch.yaml et on adapte l'utilisation avec le device ID que l'on trouvera dans l'intégration, ici remote.ir_clim_remote :

- platform: smartir
  name: AC Sejour
  unique_id: ac_sejour
  device_code: 1260
  controller_data: remote.ir_clim_remote
  temperature_sensor: sensor.mi_t_carre
  humidity_sensor: sensor.mi_h_carre
  power_sensor: binary_sensor.ac_power

Sources

Home Assistant & SSL

Maintenant que votre serveur Home Assistant est en place, il va falloir le faire communiquer avec l'extérieur de la façon la plus sécurisée possible. Sur le principe on ouvre le port (TCP/8123 en général) sur le routeur et on redirige le flux vers le serveur local. Je ne vais pas vous faire un dessin, d'autres l'ont fait. Ensuite il va falloir d'occuper de la mise en place du certificat SSL

Pour faire court deux cas de figure se présentent.

Soit votre fournisseur d'accès vous met à disposition une IP fixe, soit non, et c’est hélas le cas de beaucoup. Certains comme Free fournissent maintenant une IP fixe partagée, dans ce cas il faut demander via l'interface une IP full range. Si vous disposez de votre propre nom de domaine, et ce n'est absolument pas obligatoire pour ce genre de site, par essence privé, on va privilégier Let's Encrypt.

  • IP Fixe + Nom de domaine : Add-on Let'sEncrypt.
  • IP Dhcp avec ou sans nom de domaine : Add-on DuckDNS

L'add-on Let's Encrypt

Il s'installe depuis le superviseur et peut s’appuyer sur les API d'OVH, Gandi et CloudFlare (et bien d'autres). Si tout est bien renseigné comme ci dessous par exemple, en quelques minutes vous obtenez votre certificat et le tour est joué.

email: [email protected]  # Pour Let's Encrypt
domains:
  - ha.domain.tld  #  Domaine don le DNS est chez CloudFlare
certfile: fullchain.pem
keyfile: privkey.pem
challenge: dns
dns:
  provider: dns-cloudflare
  cloudflare_email: [email protected]  # Votre compte Cloudflare
  cloudflare_api_token: vYffF-LzhdhdhdgfhjhjjFGJFDGJJGsfgFGJSgjf

L'add-on DuckDNS

Il s'installe depuis le superviseur et nécessitera la création d'un compte sur www.duckdns.org afin de préparer la configuration. L'avantage de cet add-on c'est qu'il va tenir informé DuckDNS de vos changements d'IP.

lets_encrypt:
  accept_terms: true
  certfile: fullchain.pem
  keyfile: privkey.pem
token: 952ddsfsdf5-b1sfse-43gfsdgsdfg81-10sgsgdsg2e
domains:
  - ha.domain.tld  # Le domaine choisit lors de la création du compte.
aliases: []
seconds: 300

Alternatives

Pourquoi se compliquer la vie ? Il y a qui aiment ça... Vous pouvez donc utiliser un autre service tout autant gratuit, par exemple...

  • La passerelle SSL d'OVH qui va jouer un rôle de reverse proxy également (à condition d'avoir une IP fixe,). Dans ce cas on a la choix localement d'utiliser un certificat auto signé soit pas de SSL.
  • L'intégration CloudFlare qui semble utilisable sans IP fixe. Voir également ici pour utiliser un certificat CloudFlare.

Reverse Proxy

Se protéger avec une reverse proxy est une très bonne idée. On peut bien sur installer en local NGINX (et le configurer...) ou utiliser un reverse proxy existant dans votre infrastructure (Synology, ou HA Proxy dans pfSense par exemple), mais le plus simple est de déléguer la chose à un reverse proxy CDN, je pense bien sur à CloudFlare, en utilisant ou pas leur certificats. Attention toutefois, CloudFlare n'autorise pas tous les ports, et notamment pas le 8123, il va donc falloir ruser, soit utiliser un port externe et un port interne, soit changer le port de Home Assistant.

Que vous utilisiez ou pas un reverse proxy, il faudra vous arranger pour localement outrepasser le reverse ou le port externe de votre routeur. Inutile en effet d'aller faire un tour sur Internet pour utiliser une requête locale. En plus en cas de panne internet ça ne marcherait plus. Pour ça il faut un DNS menteur local, ça peut être un fichier host sur un PC, un DNS local sous Linux ou Windows, mais je vous conseille plutôt d’installer l'excellent add-on AdGuard qui en plus de dépolluer vos pages web fera également ce travail grâce à sa fonction de réécriture DNS. Bien sur dans ce cas il faudra que votre DHCP local pointe sur ce DNS...

Exemple

Ici j'ai configuré de façon à se que l'accès externe passe par le reverse proxy de CloudFlare (sur le port 2096), ce qui protège mes IP, j'ai fait une redirection DNS locale via AdGuard et j'utilise une URL interne sur mon mobile ou mon accès local sur PC.

URL Home Assistant : https://ha.domain.tld:2096 (pour CloudFlare par exemple).

SSID : Mon SSID (c'est sert au client mobile à savoir s'il faut appeler l'URL interne).

URL Interne : https://ha.domain.tld:8123  (ce sera également l'url local depuis un PC.)

N'hésitez pas à commenter si vous avez des questions.

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