Home Assistant : domotique vite fait, bien fait !

Depuis que j'ai emménagé dans ma nouvelle demeure, il y a presque une triplée d'années, la question ne cesse de se poser : une solution domotique oui, mais laquelle ? Vous savez comment ce genre de questionnement finit, à force d'hésiter entre plusieurs options pour ne pas investir du temps inutilement, on ne fait jamais rien. J'ai donc gratté les fonds de tiroirs pour trouver une Raspberry Pi 3B (pas « + »), avec quelques autres modules et plateformes vestiges d'articles et de projets précédents, et j'ai tout simplement tenté ma chance en me fixant un investissement temporel maximum : un week-end, pas plus. Si je ne suis pas satisfait du résultat, ou ai trop de doutes quant aux choix techniques ou la philosophie du système, je n'aurai perdu que 48 h.

Bien entendu, il était absolument hors de question de reposer sur une solution de type « cloud », qu'elle soit tout ou partie propriétaire ou entièrement open source. De mon point de vue, une solution domotique est censée gérer mon habitat, qui est la définition même du terme « privé ». Ce qui veut dire que ce qui est détecté, géré, supervisé ou contrôlé dans cet environnement n'a strictement rien à faire sur le Net, d'une manière ou d'une autre. Peu importe que ce soit la température de mon salon, l'état d'une prise de courant ou l'image de mes rhubarbes en train de pousser dans le jardin, tout ceci est dans mon environnement et restera dans mon environnement. Le système où sera installé Home Assistant, puisque c'est la solution testée, sera interdit d'accès au Net par défaut et il en va de même pour l'infrastructure sur laquelle il est branché. Ceci sort du cadre du présent article, puisqu'il s'agit purement d'administration réseau, mais ma domotique (capteurs, Wi-Fi, Ethernet, etc.) est un réseau totalement isolé (sauf ouverture ponctuelle pour maintenance/installation). Je vous conseille de faire de même, malgré l'éventuelle complexité de la chose, et ce, quand bien même il est effectivement possible (et plus simple) de brancher tout cela derrière votre box sans autre forme de procès. « Domotique = Maison = Privé » pour moi, c'est ainsi (mais je ne mets pas non plus de photos de tout ce que je mange sur Instagram, donc je ne suis peut-être pas une référence de modernité)...

1. Installation de Home Assistant sur Pi 3

Home Assistant (ou « HA » pour les intimes, parfois « HAOS ») est un projet qui existe depuis quelque temps déjà et qui a grandement gagné en maturité, mais aussi en diversité du point de vue des plateformes supportées. Il est en effet possible d'installer HA sur différents SBC (Raspberry Pi, Odroid, Tinkerboard, etc.), mais également comme une « application serveur » sur un système existant, qu'il s'agisse de GNU/Linux (x86-64), Windows ou macOS. Enfin, on peut également sortir des sentiers battus en misant sur une installation en machine virtuelle ou en conteneur, et pour les plus courageux, on peut également installer tout cela manuellement, y compris sur les systèmes qui ne sont pas listés sur le site officiel (typiquement, FreeBSD et consorts).

HA se présente en effet sous quatre formes différentes :

• un système d'exploitation complet basé sur GNU/Linux et intégrant, de base, tout le nécessaire, souvent désigné par l'acronyme « HAOS » ;
• un conteneur pour fonctionner sur un OS déjà installé (à noter que la version « OS » utilise également la conteneurisation) ;
• une VM supervisée ;
• ou enfin le projet lui-même, écrit avec un mélange de Rust et de Python et fonctionnant dans un environnement virtuel Python (venv).

Ici, nous allons faire simple puisque l'horloge tourne (48h, on a dit) et puisqu'une plateforme dédiée (la RPi) est déjà prévue à cet effet : ce sera donc HAOS. Celui-ci s'installe très simplement sur le support microSD en le recopiant à l'aide d'un outil comme dd en ligne de commandes, balenaEtcher ou encore Win32DiskImager, exactement comme on le faisait il n'y a pas si longtemps encore pour Raspbian (avant l'arrivée de Raspberry Pi Imager, voir le précédent numéro [1] à ce propos). Pour récupérer l'image à inscrire sur la carte microSD, pointez simplement votre navigateur sur https://www.home-assistant.io/installation/raspberrypi. Là, vous trouverez quatre URL de téléchargement (à cette date) :

• « Raspberry Pi 4 64-bit » : haos_rpi4-64-9.3.img.xz ;
• « Raspberry Pi 4 32-bit » : haos_rpi4-9.3.img.xz ;
• « Raspberry Pi 3 64-bit » : haos_rpi3-64-9.3.img.xz ;
• « Raspberry Pi 3 32-bit » : haos_rpi3-9.3.img.xz.

Comme le précise le site, la version recommandée est celle en 64 bits et le choix du SBC (Pi 4 ou Pi 3) dépendra de ce que vous aurez sous la main. Notez au passage que l'installation (premier démarrage) doit se faire avec une connexion Ethernet, qui est de toute façon également recommandée pour le fonctionnement courant. Il est possible de faire fonctionner l'installation en Wi-Fi, par la suite, mais c'est à éviter. Dans mon cas, l'image sera haos_rpi3-64-9.3.img.xz, qui sera décompressée avec xz -d, puis inscrite sur une carte microSD SanDisk de 32 Go avec :

Notez que j'utilise ici dcfldd, une excellente alternative à dd, mais que le même résultat peut être obtenu avec sudo dd if=haos_rpi3-64-9.3.img of=dev/disk/by-id/usb-Generic_Mass-Storage-0\:0 bs=1M conv=fsync. Dans les deux cas, le chemin pour of= (Output File) pourra également être le pseudo-fichier classique /dev/sdX, mais le lien symbolique dans /dev/disk/by-id aide à éviter une potentielle confusion catastrophique de périphériques.

Ceci fait, il vous suffira de placer la carte dans son emplacement, vous assurer que le câble Ethernet est connecté et alimenter votre framboise. Il n'est pas nécessaire de connecter un écran et un clavier au système, si ce n'est pour suivre le démarrage, mais vous devrez faire preuve de patience en attendant que ce premier démarrage règle différents éléments de configuration (redimensionnement du système de fichiers, configuration, connexion réseau, etc.). Gardez un œil sur la LED verte de la Pi, par défaut témoin d'activité de la SD, car l'absence d'activité signifie généralement que le système est près.

Lorsque c'est le cas, celui-ci devrait répondre à l'adresse homeassistant.local :

Si cela ne fonctionne pas, c'est peut-être que votre système ne sait pas faire de résolution mDNS et est incapable de trouver l'adresse correspondant à ce nom d'hôte. Vous pouvez cependant utiliser l'adresse IP directement, ici comme dans la suite de l'article.

Dirigez alors votre navigateur web à l'adresse http://homeassistant.local:8123/ et découvrez l'écran suivant afin de suivre les instructions (dont celle de patienter un bon bout de temps) :

Au terme d'une attente qui semble interminable (c'est vraiment presque 20 minutes), vous serez invité à créer un compte utilisateur :

Renseignez les informations (ceci peut être changé par la suite) et cliquez sur « Créer un compte ». Vous remarquerez que le système vous parle directement en français. Puis on vous demandera de spécifier un nom pour l'installation domotique, votre emplacement géographique sur une carte OpenStreetMap, votre fuseau horaire, votre élévation, le système unitaire (métrique chez nous et les autres gens normaux) et la devise locale (Euro). Puis arrive la page concernant la collecte de données télémétriques, toutes désactivées par défaut et c'est à vous de voir ce que vous souhaitez partager anonymement.

Enfin, le système d'installation va très certainement détecter des périphériques utilisables comme des services DLNA (serveur multimédia), des appareils Bluetooth ou éventuellement des capteurs Wi-Fi reconnus. Vous pouvez configurer ces matériels immédiatement ou le faire par la suite, de manière plus contrôlée et ordonnée.

Une fois cette dernière étape passée, vous voici catapulté sur la page d'accueil d'Home Assistant qui est... pleine de vide :

La seule information que nous voyons est la prévision météo, tirée de notre emplacement géographique précédemment renseigné (chose qui ne restera pas dans mon installation qui sera hors Net après configuration). Un petit clic sur l'icône vous donnera un aperçu du fonctionnement et de l'interface de HA (appelée Lovelace UI dans les documentations), avec des fenêtres popup, des onglets et des paramètres ajustables pour ce module. Cette page d'aperçu est le tableau de bord par défaut, géré par HA, où apparaîtront les nouvelles « entités » (généralement, des capteurs) et de nouveaux éléments de visualisation. La logique de HA consiste à présenter ces informations sur autant de tableaux que l'utilisateur décidera de créer. Prenez le temps de vous familiariser avec cette interface pour en comprendre la logique, qui est parfois un peu déroutante en termes d'utilisation de l'espace.

Si vous allez faire un tour dans « Paramètres » (à droite en bas), puis « Appareils et Services », vous découvrirez tout ce que HA peut utiliser et c'est ici que vous retrouverez les éventuels périphériques autodétectés, comme mon vieux media player NP2900 :

Mais avant de faire quoi que ce soit, il est important de comprendre le jargon utilisé par HA. Un appareil peut être un matériel, un objet connecté ou encore un périphérique comme un smartphone. C'est l'objet qui physiquement communique avec HA. Une entité est l'élément de base de HA et il est important de ne pas le confondre avec l'appareil. Si, par exemple, vous créez un montage à base d'ESP8266 et comportant un capteur BME280 (température, hygrométrie, pression), vous verrez apparaître trois entités distinctes, une pour chaque donnée mesurée.

Dans HA, on peut dire que « tout est entité », car il ne s'agit pas que des capteurs qui prennent cette forme, mais également l'installation domotique elle-même (entité « Maison ») ou encore vous-même, en tant qu'utilisateur. On peut voir cela comme des objets d'un langage de programmation, ce sont des « choses » manipulées et gérées par HA. Ces entités possèdent un certain nombre d'informations qui les caractérisent, dont un nom, un identifiant (ID), une icône, un état et une liste d'attributs. Ils sont également généralement associés à une pièce de votre habitat.

C'est d'ailleurs, à mon sens, la première chose à faire pour configurer votre installation : définir les pièces pour pouvoir facilement, ensuite, placer les entités qui seront détectées au fur et à mesure que nous créerons et ajouterons des capteurs et autres appareils.

2. Personnaliser Home Assistant

Pour créer vos pièces, rendez-vous dans « Paramètres », puis « Pièces et zones ». Une pièce est un endroit que vous utiliserez pour placer vos appareils et entités. Généralement, il s'agit de pièces physiques et HA en a déjà prévu trois par défaut : « Chambre », « Cuisine » et « Salon ». Vous ne devez cependant pas réfléchir comme un agent immobilier, mais plutôt voir cela comme votre terrain de jeu. En effet, une entrée, des escaliers, un perron ou un débarras ne sont généralement pas considérés comme des pièces, mais il peut s'agir d'un endroit où vous pourriez souhaiter mettre un capteur de lumière ou de température. Structurez donc votre demeure en ce sens dans HA. Les zones, quant à elles, sont des « régions ». Votre installation domotique, désignée par défaut avec le nom « Maison » est une zone. Celle-ci, et d'autres si vous les créez, peuvent servir de périmètre de détection pour suivre les appareils présents et servir de déclencheurs dans vos futurs scénarios.

Ceci fait, même à peu près correctement seulement (il est toujours possible de changer les noms par la suite et de créer des nouvelles pièces), il est temps d'ajouter quelques fonctionnalités à notre installation. Si vous avez un peu fouillé rapidement dans l'interface, vous avez sans doute dû remarquer que HA, dans l'état, est déjà très riche en fonctionnalités. Il est ainsi capable de détecter et de prendre en charge énormément de périphériques et services en ligne. C'est le cas, par exemple, de mon media player NP2900, mais également du service de météo présenté par défaut sur le tableau de bord. Si vous retournez dans « Appareils et Services » et cliquez « Ajoutez une intégration », vous constaterez rapidement qu'il y a pléthore de choix : 1-Wire pour un capteur attaché à la Pi, AccuWeather pour la météo, Amazon Alexa, Apple TV, Google Calendar, MQTT ou encore ESPHome dont nous allons nous servir.

Dans le cas d'une installation « Core », ces services ne seront pas forcément proposés, car l'instance de HA serait plus ou moins « nue ». Heureusement pour nous, avec la version « HAOS », ce n'est pas un problème. Mais nous allons tout de même utiliser le mécanisme de « Modules complémentaires », à la fois pour prendre en main le système et aussi pour installer quelque chose qui me paraît être indispensable : une ligne de commandes.

Avant toute chose, nous devons rassurer HA en lui confirmant que nous sommes des gens qui savons ce qu'ils font. Un certain nombre de fonctionnalités et de modules sont cachés par défaut et nous devons activer le « Mode avancé » pour nous-mêmes. Pour cela, cliquez sur votre identifiant situé en bas à gauche de l'écran et dans la longue liste de paramètres, activez « Mode avancé ». Vous pourrez ensuite vous rendre dans « Paramètres », puis « Modules complémentaires ». Comme rien n'est installé pour l'instant, on vous propose de faire un tour dans la boutique des modules où vous découvrirez une quantité phénoménale d'extensions disponibles. Là, cherchez « SSH » et, dans les résultats, choisissez « Terminal & SSH ». Cliquez sur « Installer » et le tour est joué.

Ceci prend un peu de temps, mais le module sera bien installé, soyez patient. Ceci fait, activez l'option « Afficher dans la barre latérale » pour avoir à disposition un terminal pour pouvoir saisir des commandes et interagir avec le système. Et enfin, cliquez sur « Démarrer » pour lancer le service immédiatement (sans avoir besoin d'un redémarrage).

Notez que ce terminal vous propose un shell root, mieux vaut donc être prudent. Et autre point intéressant, ceci s'exécute dans un conteneur :

L'utilisation via l'interface web est intéressante, mais assez peu ergonomique pour qui a l'habitude d'un terminal « normal ». Il est possible de configurer l'accès SSH depuis l'extérieur du système, mais ceci demande un peu de technicité. Dans un premier temps, nous allons générer, sur la machine cliente (celle depuis laquelle vous vous connectez), une nouvelle paire de clés RSA :

Il est possible de s'authentifier avec un simple mot de passe, mais ceci est déconseillé par l'interface, la documentation, moi et plus ou moins tout le monde. Le fait d'utiliser une clé générée spécialement à cette occasion et non celle courante pour l'utilisateur ajoutera encore une légère couche de sécurité. Ce qui nous intéresse dans cette génération, c'est le contenu du fichier HArsa.pub, la clé publique associée à la clé privée HArsa qui ne quittera pas la machine.

Vous devrez ensuite vous rendre dans l'interface de configuration de HA, menu « Paramètres », « Modules complémentaires », « Terminal & SSH », onglet « Configuration ». Là, cliquez sur les trois points en haut à droite et sélectionnez « Modifier en tant que YAML », ce qui vous donnera accès à la configuration en langage YAML. Dans la zone qui apparaît, spécifiez la configuration suivante :

La ligne débutant par « ssh-rsa » est celle provenant du HArsa.pub. Il est recommandé d'entourer cette information de guillemets pour éviter que le contenu ne soit interprété comme du YAML. Enregistrez la modification, puis plus bas, spécifiez un numéro de port TCP à autoriser à la section « Réseau ». Attention, l'interface est trompeuse, le « 22/tcp » à droite n'est qu'un indicateur, pas la valeur actuellement utilisée qui apparaît à gauche lorsqu'elle est spécifiée. Lorsque vous enregistrerez cette valeur, acceptez de redémarrer le service et patientez.

En attendant, sur votre machine cliente, il peut être intéressant de modifier la configuration du client SSH via l'édition du fichier ~/.ssh/config pour ajouter :

Ceci nous permettra de tout simplement utiliser ssh ha, sans avoir à spécifier d'identité ou d'autres arguments en option pour ajuster la bonne clé RSA à prendre en compte. Remarquez tout de même que l'utilisateur est root et que permettre ce genre d'accès n'est pas quelque chose qu'il convient de faire en permanence. Mieux vaut activer le service au besoin et, si vous n'avez pas d'autres choix, laissez la clé privée sur une unique machine (voir un support externe) et changez régulièrement le mot de passe qui la protège (car vous avez bien spécifié un mot de passe, n'est-ce pas ?).

Quoi qu'il en soit, vous devez maintenant avoir un accès SSH direct :

L'intérêt de toutes ces manipulations n'est pas simplement de pouvoir jouer avec un shell, mais d'utiliser la commande ha (anciennement hassio) qui permet de faire littéralement tout ce qu'il est possible de faire via l'interface web Lovelace, mais en ligne de commandes. Nous resterons, dans le reste de l'article, dans la démarche standard, mais prendre l'habitude d'utiliser ha est vraiment une bonne chose pour votre installation. D'autant qu'en cas de problème, cela semble être la méthode par défaut des utilisateurs avancés susceptibles de vous aider sur les forums officiels.

3. Ajoutons des choses et « domotisons »

Home Assistant installé ainsi sur un SBC n'a pas vraiment d'intérêt en tant que tel, même s'il est déjà capable, par lui-même, de faire certaines choses (par exemple, si vous installez l'application Android [2] ou iOS [3] sur votre smartphone). Tout l'intérêt de ce genre d'installation est, bien entendu, de truffer son habitat de capteurs et de dispositifs de contrôle en tous genres.

3.1 Transformer une Pi 2 en caméra de surveillance

Avant d'entrer dans des considérations plus techniques impliquant des ESP8266 et différents montages permettant des mesures environnementales, commençons par quelque chose de plus facile à mettre en œuvre : de la surveillance vidéo. Je dis bien « à mettre en œuvre », car le choix du matériel peut s'avérer assez épineux. En effet, il existe une myriade de produits sur le marché et parmi ceux les moins chers, la sélection est encore moins aisée. Ceci du fait, non seulement, qu'un même produit peut exister sous bien des noms et qu'un même nom de produit ne vous garantit absolument pas que vous recevrez le même matériel que celui qu'aura reçu un acheteur quelques mois auparavant. Et tout cela avec le risque que la caméra en question soit beaucoup trop bavarde et se permette de capturer des images fixes et des vidéos à votre insu pour les envoyer on ne sait où (ce n'est pas une théorie, c'est un fait avéré sur quelques produits très entrée de gamme). Bien entendu, des firmwares alternatifs existent, mais la chasse au bon matériel est une activité à part entière et la mise à jour un autre sujet d'article. Dans les deux cas, nous ne sommes plus dans le concept de l'installation domotique en un week-end.

Une autre approche possible consiste à, tout simplement, créer sa caméra de surveillance de toutes pièces, aussi simplement et rapidement que possible. Ceci peut paraître irréaliste, mais ce serait sans compter le travail effectué par le projet motionEye et ses développeurs. motionEye [4] est un frontend web pour l'utilitaire Motion [5] qui existe depuis fort longtemps. Comme son nom l'indique, le travail de Motion consiste à prendre en charge un flux vidéo (local, V4L2, carte de capture, flux RTSP, RTMP, HTTP, etc.) et à le traiter de différentes manières :

• enregistrer des vidéos et images fixes ;
• afficher un flux vidéo ;
• déclencher des scripts en cas de détection d'activité ;
• garder un journal des événements ;
• retransmettre le flux vidéo ;
• etc.

motionEye, initialement développé par Calin Crisan, est une surcouche à cela et permet de contrôler le comportement de Motion via un navigateur, et ce, pour une ou plusieurs caméras et périphériques d'acquisition. En considérant un SBC quelconque, il est donc parfaitement possible de lui attacher physiquement une caméra et de transformer le tout en une caméra connectée accessible via le réseau (localement ou non). Bien sûr, cela implique d'installer un système, ajouter motionEye, configurer le service, etc. C'est bien trop compliqué pour un projet rapide permettant de se donner le temps de choisir une appliance de surveillance adaptée à ses besoins et sûre...

Fort heureusement, un projet annexe de motionEye est motionEyeOS, une distribution clé en main, basée sur BuildRoot, intégrant de base Motion et motionEye sans que vous ayez besoin de mettre trop les mains dans le cambouis. motionEyeOS est disponible, sous forme d'image de système de fichiers, pour plusieurs plateformes :

• Banana Pi M1 ;
• Nano Pi Neo2 ;
• Odroid C1/C1+ ;
• Odroid C2 ;
• Odroid XU4/XU4Q/HC1/HC2/MC1 ;
• Orange Pi One ;
• Pine A64/A64+ ;
• Tinker Board ;
• Raspberry Pi (A, B, A+, B+, CM, Zero et Zero W) ;
• Raspberry Pi 2 ;
• Raspberry Pi 3 (B, B+, A+ et CM3) ;
• Raspberry Pi 4.

Le choix du SBC se fera en fonction de ce que vous avez sous la main, en jugeant ce qu'il est judicieux ou non de monopoliser comme ressources. Pour ma part, une Pi 3 ou 4 est absolument hors de question, même si quatre cœurs peuvent s'avérer utiles si l'on compte gérer plusieurs caméras. La Raspberry Pi 1 en revanche est clairement sous-dimensionnée dès lors que l’on compte utiliser une résolution digne de ce nom. Reste donc la Pi 2 qui semble un bon compromis, du moins pour une solution temporaire, en particulier en utilisant une RaspiCam directement connectée au port MIPI CSI-2.

Pour créer le support d'installation (carte microSD), il suffira de pointer son navigateur sur la page listant les SBC supportés [6], télécharger l'image correspondante (motioneyeos-raspberrypi2-20200606.img.xz), la décompresser avec xz et la transférer très classiquement sur le support avec l'outil de votre choix, exactement comme on le ferait pour Raspbian. Remarquez que le système n'occupe qu'environ 350 Mo, ce qui permet de se servir d'une microSD de petite taille qui par ailleurs ne serait pas forcément utilisable.

Si vous souhaitez que votre caméra motionEye fonctionne directement en Wi-Fi (avec un adaptateur USB par exemple sur une Pi 2), dès le premier démarrage, vous devrez composer et personnaliser un fichier wpa_supplicant.conf contenant :

monSSID et phrase2passe devront être, bien entendu, ajustés en fonction de votre installation. Il vous faudra ensuite monter la partition FAT de la carte SD (celle contenant cmdline.txt, kernel.img, etc.) et y copier ce fichier. L'alternative est, bien entendu, d'utiliser la connexion Ethernet. Dans les deux cas, après insertion et démarrage du SBC, viendra le moment de jouer à « Devine mon IP ». La solution facile consiste à brancher un moniteur HDMI (si disponible) et à suivre les messages de démarrage pour repérer l'adresse utilisée. Vous pouvez également visiter l'interface web de votre box ou de votre routeur pour lister les périphériques ayant obtenu une adresse via DHCP, repérer un hôte dont le nom débute par « meye » et utiliser son IP. Notez que le premier démarrage peut durer plusieurs minutes.

Accédez enfin à motionEye avec votre navigateur et vous tomberez sur un formulaire de connexion. Là, entrez simplement « admin » sans mot de passe et vous accéderez à l'interface de gestion, présentant normalement déjà une image obtenue de la caméra (si RaspiCam, du moins). En haut à gauche se trouve une icône permettant de déplier un formulaire listant tous les paramètres configurables, dont le nom d'utilisateur administrateur et son mot de passe que vous vous empresserez de changer. Un second utilisateur, le Surveillance User, qui ne peut que voir et non configurer, peut également être spécifié. Vous pourrez aussi régler le fuseau horaire, les paramètres réseau, les services activés (FTP, SSH, Samba) ou encore la résolution, le nombre d'images par seconde, l'orientation de la caméra ou le texte à placer en surimpression.

Vous l'aurez sans doute compris, vous pourrez utiliser plus d'une caméra avec cette installation de motionEyeOS. Ce sera peut-être l'occasion de recycler de vieilles webcams compatibles V4L2, mais n'oublier pas que plus vous en ajouterez, plus le SBC peinera à suivre, en particulier une pauvre Pi 2. Mais en ajustant les résolutions, il sera possible de configurer ce système pour surveiller toute une zone sous plusieurs angles de vue (comme une entrée, un parking et une cour).

À ce stade, et une fois que vous aurez fait le tour du propriétaire pour tout ajuster à votre convenance, vous disposerez d'un système de surveillance assez étoffé, capable de détection et d'enregistrement d'images et de vidéos. Notez au passage que ma propre configuration utilise effectivement la caméra MIPI du SBC et aussi une webcam C920 USB, mais que l'objectif n'est pas la capture ou même la détection. Celles-ci sont utilisées pour le jardin où les mouvements des végétaux (vent) rendent la détection délicate en plus d'être plutôt inutile, à mon sens.

Cependant, tout l'intérêt de Home Assistance est de centraliser les informations et précisément vous éviter de devoir aller à la pêche aux informations manuellement. Nous allons donc intégrer notre installation motionEye à notre HA. Pour ce faire, rendez-vous dans « Paramètres », « Appareils et Services » puis « Ajouter une intégration ». Cherchez alors « motionEye » et dans le formulaire qui est présenté, spécifiez l'URL (http://IP), le nom et le mot de passe de l'utilisateur administrateur et le nom et mot de passe de l'utilisateur de surveillance, puis validez. Si l'ajout est un succès, HA vous demandera alors, pour chaque source vidéo (caméra), de spécifier une pièce et de terminer l'intégration. Vous verrez alors apparaître une nouvelle entrée sur la page avec autant d'appareils que de caméras gérées et un grand nombre d'entités (8 pour chaque caméra), représentant les différentes « fonctionnalités » ou « capacités » disponibles.

Ce ou ces périphériques seront automatiquement ajoutés au tableau de bord autogéré par HA, mais n'utiliseront pas un débit d'image maximum (rafraîchissement toutes les 10 s) pour ne pas surcharger le système. Vous pourrez alors simplement cliquer sur l'image pour avoir une vue « temps réel » avec le débit réglé dans motionEye.

3.2 Prise en main de ESPHome

Dans le monde de la domotique « faite maison » et dès lors qu'il s'agira de capteurs, de contrôleurs ou autres montages satellites à relier avec Home Assistant, vous entendrez généralement deux noms : Tasmota et ESPHome, et probablement énormément de gens argumentant pour l'un ou pour l'autre. Les deux projets visent le même objectif et règlent le même problème, car problème il y a. Imaginez un instant que vous deviez confectionner vous-même le firmware d'un montage remontant des informations à HA ou, inversement, recevant des ordres de sa part. Après étude de l'API de HA et/ou des solutions de communication via MQTT (voir Hackable 26 [7]), vous voici en train de développer votre petit projet. Vous l'intégrez à HA et, quelque temps après, vous attachez un nouveau capteur et vous recommencez le processus. À force, vous finirez par développer une certaine structure, vous permettant d'accélérer la création de nouvelles sondes, mais selon la plateforme utilisée, le ou les composants mis en œuvre, il y a toujours une part importante de développement. Vous n'en aurez jamais fini.

Imaginez alors disposer d'une collection de briques, déclinées pour plusieurs plateformes et prenant en charge différents composants et capteurs. L'assemblage de ces briques reposera sur un socle de base auquel s'ajoutent les modules nécessaires et le tout sera recompilé automatiquement et flashé dans vos montages. Poussez encore plus loin, et structurez cela autour d'un script de configuration réutilisable et/ou une interface dédiée. Bravo, vous venez de créer un nouveau concurrent à ESPHome et Tasmota.

Beaucoup parlent de « firwmare » Tasmota et/ou ESPHome, mais vous comprendrez, après ce petit descriptif, qu'il ne s'agit pas exactement de ça. Il serait plus judicieux de parler de « framework de construction de firmwares », mais l'idée est somme toute la même. Il s'agit de vous éviter du développement pour créer/recréer quelque chose qui a déjà été fait des centaines de fois par des centaines de développeurs, pour des montages qui n'ont souvent qu'un seul usage. Ceci, bien entendu en vous laissant suffisamment d'espace de liberté pour ajuster des points (comme les GPIO utilisés) ou combiner des fonctions.

Fonctionnellement, il n'y a que peu de différences entre Tasmota et ESPHome et, bien entendu, des périphériques créés à partir de l'un ou l'autre framework fonctionneront avec Home Assistant. C'est davantage une question d’ergonomie et de confort d'utilisation dont il s'agit et, également, de plateformes supportées. Tasmota est uniquement compatible avec ESP8266 et ESP32 (qui est un ajout récent). ESPHome supporte les deux familles de microcontrôleurs presque depuis le début et vient dernièrement d'ajouter le RP2040 ou, en d'autres termes, les cartes Raspberry Pi Pico W. Enfin, le point le plus important concerne la manière de composer vos capteurs. Tasmota est excessivement orienté vers les interfaces graphiques et GUI, alors qu'ESPHome base massivement cela sur des fichiers de configuration en langage YAML (le même que celui utilisé par HA). Je n'aime pas particulièrement YAML, que je considère comme syntaxiquement laid et difficilement lisible (comme tous les langages où les espaces et l'indentation font partie de la syntaxe), mais je trouve cela bien plus souple que d'être contraint d'utiliser une interface donnée. C'est donc, naturellement, en premier lieu vers ESPHome que j'ai décidé d'aller et donc de vous y emmener avec moi.

Notez que si vous souhaitez quelque chose de plus graphique, il existe une possibilité d'avoir une interface intégrée dans HA via le module complémentaire « ESPHome » installable via l'interface web et la « Boutique des modules ». Sachez cependant qu'il existe des problèmes de compatibilité avec certains navigateurs concernant la possibilité de programmer vos cartes microcontrôleurs directement de cette manière. La ligne de commandes est, et restera toujours, la manière la plus efficace de configurer quelque chose.

En ce qui nous concerne et ce qui concerne le présent article, la ligne de commandes et l'utilisation de conteneur Docker est la voie que nous emprunterons. Le projet ESPHome met à disposition une image Docker disponible via le hub officiel [8] qu'il est très facile d'utiliser, tout est parfaitement géré. Tout ce qu'il vous faut, c'est une machine capable de faire fonctionner Docker, qu'il s'agisse d'un PC ou d'un SBC puissant. Sur une plateforme compatible Debian/Raspbian/Ubuntu, ceci s'installera via sudo apt-get install docker docker.io (et assurez-vous que l'utilisateur courant soit dans le groupe docker et ait accès aux périphériques série via le groupe plugdev). L'image Docker fonctionnera sans problème avec une machine ayant une architecture AMD64, ARM ou ARM64 (alias AARCH64), et probablement aussi avec une machine virtuelle (non vérifié et sous réserve de permettre l'accès aux périphériques USB physiques).

L'installation se fait via une simple ligne de commandes :

Dès lors, vous aurez le nécessaire pour créer, configurer et programmer les plateformes supportées, sans perturber la configuration de votre système. Bien entendu, plus la machine sera puissante, plus tout cela fonctionnera rapidement. Si vous voulez en savoir plus sur l'utilisation de Docker, en particulier dans un contexte comme celui-ci (de développement sur microcontrôleur), je vous recommande la lecture de mon article sur le sujet dans le numéro 41 [9].

Enfin, à toutes fins utiles, ne vous inquiétez pas de l'aspect ligne de commandes et fichier de configuration. Non seulement ESPHome utilise des wizards permettant d'initier facilement un projet de base, mais la syntaxe elle-même des fichiers YAML est relativement simple. Et nous allons voir cela immédiatement, puisqu'il est temps de créer notre premier projet...

3.3 ESP32CAM avec ESPHome

Puisque notre premier ajout à notre installation de Home Assistant a été une caméra de surveillance, continuons sur notre lancée pour surveiller à souhait (comme en Chine avec les pauvres habitants, mais ici, c'est un lave-linge que nous allons oppresser, vous allez comprendre). Ayant collecté toutes les webcams utilisables de la maison, il était temps de passer à une classe de périphérique un peu plus limité : l'ESP32Cam précédemment utilisée pour le numéro 33 [10], étant donné que je ne les ai pas toutes détruites (en retirant le miroir chaud devant le capteur CMOS pour en faire des caméras à infrarouge + lumière visible).

Si vous avez raté cet épisode mémorable, sachez que les ESP32Cam, comme leur nom l'indique, sont des cartes microcontrôleurs à base d'ESP32-S2 équipées d'une minuscule caméra et d'une PSRAM complémentaire pour augmenter leur mémoire (SRAM). Ces modules, dont le prix est aussi ridicule que la taille (6 € à 8 € pièce), ne sont, bien entendu, pas aussi performants en termes de résolution et de débit qu'une caméra Wi-Fi ou notre caméra motionEye, mais feront parfaitement l'affaire pour des choses relativement basiques comme avoir un simple aperçu d'une pièce, garder l’œil sur l'état d'une porte ou d'un volet (ouvert ou fermé) ou éviter d'aller voir si le lave-linge à la cave est arrivé au bout de son cycle et s'est éteint (j'avais dit que vous comprendriez).

Le problème, en revanche, est leur programmation (du moins la première, ensuite c'est OTA). En effet, contrairement aux autres cartes et modules ESP32 et ESP8266, ceux-ci ne disposent pas d'interface USB/série permettant la connexion à une machine. Il est donc nécessaire de faire usage d'un adaptateur externe et de procéder à quelques jongleries lors de l'enregistrement d'un nouveau firmware. Plusieurs broches doivent être connectées pour programmer l'ESP32Cam :

• masse et alimentation 3,3 V directement depuis l'adaptateur USB/série ;
• RX et TX entre des deux ;
• IO0 relié à la masse pour forcer le mode programmation.

Ce dernier point peut être résolu à l'aide d'un simple cavalier si l'on réserve la broche « GND » juste à côté à cet effet et en utilisant l'autre, près de la LED blanche, pour l'adaptateur USB/série. On se tournera ensuite vers Docker après s'être placé dans un répertoire quelconque créé pour l'occasion (pour centraliser toutes ses configurations YAML à un seul endroit) :

espcam.yaml est le fichier YAML que le wizard créera pour nous grâce aux réponses que nous donnerons ensuite. Le reste n'est composé que d'arguments destinés à lancer correctement le bon conteneur et à l'effacer ensuite. Ce qu'on vous demandera se décompose en quatre grandes étapes :

Le nom qui est demandé est celui du « node ». Ce n'est pas celui d'un profil réutilisable, mais bel et bien celui du périphérique. Nous verrons ensuite que le wizard n'est pas nécessaire si nous avons plusieurs périphériques identiques, une fois suffira.

On nous demande tout d'abord de quelle famille de microcontrôleur il s'agit, ici ESP32, pour directement embrayer sur la désignation plus précise du périphérique dans la longue liste proposée, ici esp32cam.

Naturellement, on vous demande ici de spécifier le point d'accès à utiliser (monSSID) et le mot de passe à correspondant (phrase2passe). Et nous arrivons à la dernière étape :

La mise à jour OTA ou remplacement du firmware via Wi-Fi est un classique des plateformes ESP32 et ESP8266. Bien entendu, cette fonctionnalité ne peut être accessible qu'après avoir spécifié un mot de passe correspondant (123456). Au terme de cette procédure, vous retrouverez, dans le répertoire courant, un sous-répertoire .esphome dont nous ne nous occuperons pas, mais aussi, et surtout un magnifique fichier espcam.yaml qui résume notre configuration. Ce fichier appartiendra très certainement au super-utilisateur root et vous devrez soit en changer le propriétaire, soit l'éditer via sudo.

Car effectivement, le wizard ne fait que nous fournir un squelette :

On retrouve ici les éléments que nous avons spécifiés, mais également un point d'accès de secours (« fallback hotspot ») nous permettant de nous connecter au périphérique directement en cas de problème de connexion cliente avec le point d'accès spécifié. Dans ce cas, l'ESP32 se comportera comme un point d'accès et nous pourrons ajuster la configuration sans avoir à le reflasher. Vous pouvez, bien entendu, changer le mot de passe pour quelque chose de plus facile à mémoriser ou, au contraire, changer cette valeur pour chaque ESP32Cam flashé.

Cette configuration ne prend pas en compte la caméra attachée au module, nous devons ajouter cela manuellement. Étant donné qu'il existe plusieurs déclinaisons de ce matériel, nous devons spécifier comment est connectée la caméra, ainsi que différents paramètres concernant son utilisation :

Le matériel en œuvre ici est un module ESP32Cam de DM DIY More et la configuration est celle correspondant à ce que nous avions découvert ensemble dans le numéro 33 (celle d'une « Ai-Thinker Camera »). D'autres déclinaisons sont prises en charge et listées sur le site du projet ESPHome [11]. Vous pourrez vous en inspirer pour adapter cela à votre produit. Notez que je n'ai pas poussé la configuration à ses limites, loin de là. Étant donné la qualité d'image, j'ai préféré baisser la résolution pour obtenir un débit presque satisfaisant, sans oublier que l'objectif n'est pas réellement d'avoir une surveillance en temps réel comme avec motionEye.

Le module ESP32Cam est également équipé d'une LED blanche de forte intensité pouvant être utile dans un environnement obscur (comme une cave). Nous pouvons ajouter cela dans la configuration YAML :

Nous obtiendrons alors une seconde entité pour cet appareil, et nous pourrons en contrôler le comportement dans Home Assistant. Il est maintenant temps d'utiliser cette configuration pour produire un firmware et flasher l'ESP32. Encore une fois, c'est Docker qui entre en jeu :

Plusieurs arguments de la ligne de commandes sont importants ici. Nous avons tout d'abord --network=host qui permettra au conteneur d'accéder au réseau et d'installer automatiquement tout le nécessaire pour construire le firmware. En coulisse, c'est PlatformIO qui entre en jeu et se verra complété d'une installation du SDK Espressif Systems (ESP-IDF) et tout ceci doit être récupéré du Net. --device=/dev/ttyUSB0 nous permet de spécifier le port où est connecté l'adaptateur USB/série relié à l'ESP32 qui aura été préalablement réinitialisé avec IO0 à la masse (cavalier) pour se trouver en mode programmation. Enfin, run espcam.yaml exécute esphome/esphome dans le conteneur tout en spécifiant notre fichier YAML de configuration.

La procédure s'arrête sur une question à propos, justement, de la méthode d'accès au microcontrôleur à cet effet. Pour cette première programmation, nous n'avons d'autre choix que d'utiliser la liaison série (choix 1), mais les mises à jour suivantes pourront se faire en Wi-Fi via l'OTA. Le choix fait, la procédure se poursuit avec l'écriture du firmware en flash :

Normalement, avec une carte ESP32 ou ESP8266 « standard », il ne devrait pas y avoir d'arrêt ici puisque les outils de programmation, idf.py et/ou esptool.py procèdent à un reset pour sortir du mode de programmation via la ligne RTS du port série. Dans notre cas, cette ligne n'est pas connectée et le reset doit être fait manuellement. Tout en laissant l'ensemble sous tension, retirez le cavalier et appuyez sur le bouton « RST » situé à côté du régulateur de tension. Ce faisant, nous arrivons directement dans le moniteur de l'ESP-IDF où nous pouvons voir la progression de ce premier démarrage :

Le firmware ESPHome est très bavard et nous affiche l'ensemble de la configuration ainsi que toutes les informations de connexion, pour ensuite boucler sur plusieurs occurrences de « Got Image », indiquant une acquisition réussie depuis la caméra embarquée. Vous pouvez quitter le moniteur avec Ctrl+] (si ça ne marche pas, un Ctrl+C fera également l'affaire).

Ce premier démarrage n'est pas passé inaperçu côté Home Assistant qui a immédiatement détecté le nouvel appareil et vous propose de l'intégrer :

Vous êtes alors invité à spécifier un mot de passe pour achever l'installation (il s'agit du mot de passe de l'API HA), et à choisir la pièce dans laquelle se trouve l'appareil et celui-ci sera ajouté à la liste déjà présente. Les deux entités apparaîtront également au tableau de bord :

Remarquez que l'interrupteur contrôlant la LED blanche est également accessible et un simple clic vous confirmera son bon fonctionnement (étonnamment rapide, d'ailleurs). Un clic sur l'image vous affichera une vue « temps réel » de la capture et même si la qualité n'est pas fantastique, le résultat est assez bluffant pour un budget à l'unité dépassant à peine les 5 €.

3.4 Simplifier le YAML

Avant d'attaquer la suite, revenons un instant sur la syntaxe YAML utilisée pour décrire la configuration du périphérique. Si, comme moi, il vous paraît bien étrange de n'acheter qu'un seul exemplaire d'un module ou d'une carte à une poignée d'euros, il est fort probable que vous ayez d'autres exemplaires d'ESP32Cam en votre possession. Celles-ci seront donc très certainement intégrées comme la première, jusqu'à être à court de périphériques ou de pièces (ou de prises de courant pour les alimenter).

Là, plusieurs approches sont possibles, dont l'édition récurrente du même fichier pour ajuster les différentes occurrences de « espcam1 » ou la simple multiplication des fichiers, un par périphérique. Pourquoi ne pas adopter les deux approches et combiner cela avec les fonctionnalités qu'introduit ESPHome dans YAML (depuis la version 1.10.0) ?

Commençons par quelque chose que vous risquez de voir souvent dans les exemples de configuration : l'utilisation de !secret. Cette directive vous permet de placer les éléments « sensibles » dans un fichier distinct et donc de ne pas les faire apparaître dans la configuration de base. Lorsque l'analyseur syntaxique voit un !secret, il va automatiquement tenter de chercher la « variable » de substitution dans un fichier secrets.yaml. Ainsi, nous pouvons créer ce fichier ainsi :

Puis utiliser ces éléments en modifiant une partie de notre espcam.yaml :

Nous pouvons pousser plus loin encore pour sortir davantage d'éléments du fichier espcam.yaml en utilisant un opérateur d'inclusion. Nous créons donc un fichier wifi.yaml et y déplaçons une partie des lignes :

Et nous faisons de même avec un fichier auth.yaml :

Puis remplaçons les lignes supprimées de espcam.yaml par :

Le contenu des deux fichiers se retrouvera placé à cet endroit et nous pouvons même déplacer wifi.yaml, auth.yaml et secrets.yaml dans un sous-répertoire inc/, tout en changeant ces deux lignes en :

Ainsi, dans le répertoire courant, nous n'avons plus que le fichier de configuration de base et les éléments communs ou invariables sont centralisés dans inc/. Et nous en arrivons enfin à la cerise sur le gâteau, réglant notre problème de récurrence initiale, grâce aux substitutions. Si nous ajoutons ceci, au début de notre espcam.yaml :

Nous pouvons utiliser $devicename partout où nous avons besoin de ce nom :

Il nous suffit alors de changer la valeur de devicename en ligne 2 pour instantanément rendre notre configuration utilisable pour une espcam2, espcam3, espcam4, etc. Et cela fonctionnera également dans les fichiers inclus comme wifi.yaml et le nom du point d'accès de secours :

Mais attendez, ce n'est pas fini. Il reste la cerise sur la cerise sur le gâteau, puisque cette substitution peut être définie ou remplacée en ligne de commandes. Ainsi, nous pouvons tout simplement utiliser :

L'option -s, pour « substituer », est utilisée par la commande esphome à l'intérieur du conteneur et nous pouvons flasher nos ESP32Cam en série, sans éditer le moindre fichier. Problème réglé !

Nous pourrions pousser encore davantage (en sortant la configuration de la caméra, par exemple), mais vous avez compris le principe. Nous avons là une boîte à outils permettant de modulariser totalement nos configurations et je vous recommande de jeter un œil à la documentation officielle [12] sur les différentes syntaxes utilisables dans ce sens.

3.5 Interrupteur Sonoff avec ESPHome

Après ces petits ajustements en YAML, les choses vont devenir bien plus simples et même si nous pouvons toujours utiliser le wizard pour créer une structure de base, il deviendra plus facile et plus rapide, au fil du temps, d'écrire directement les configurations YAML à la main.

À ce stade, notre système domotique est davantage un système de surveillance qu'une « domotisation » d'un habitat. Deux choses sont généralement associées à la notion de domotique : la mesure et le contrôle. En d'autres termes, relever des informations (mouvement, température, hygrométrie, état d'un système, etc.) et actionner des appareils et des mécanismes (luminaire, ventilation, chauffage, pompe, arrosage, etc.).

Commençons donc par le contrôle et en particulier par quelque chose d'aussi simple que courant : piloter l'alimentation d'appareils et, le plus souvent des luminaires. Ici, il ne sera pas nécessaire de créer un montage de toutes pièces, car des produits existent, pouvant parfaitement être reflashés avec un firmware open source, comme justement ceux produits par ESPHome. D'autre part, je soulignerai que créer un montage équivalent est certes possibles, après tout il ne s'agit que d'un microcontrôleur Espressif, un transistor, un relais, une alimentation, un bouton, une LED et quelques composants passifs, mais n'est pas forcément une bonne idée. Non seulement la forme que prendra le résultat ne sera probablement jamais aussi « propre » et intégrée qu'un produit du marché, mais en plus, il faut prendre en compte le facteur risque. On parle ici de contrôler une tension domestique, avec laquelle on ne plaisante pas. Il existe des règles et des normes et elles ne sont pas là par hasard. Les 230 V alternatifs présents dans nos demeures se doivent d'être traités avec prudence et respect, c'est une tension potentiellement mortelle, que ce soit directement ou en tant que cause d'incendie. Ceci est valable pour ce que nous allons faire et pour un montage « maison ».

Il existe nombre de périphériques capables d'être utilisés avec HA, mais en ce qui concerne le contrôle d'alimentation, le nom que vous verrez le plus souvent est sans le moindre doute « Sonoff ». Il s'agit d'une marque et d'un fabricant spécialisé dans les « smart devices » proposant une vaste gamme de produits, compatibles avec énormément de solutions domotiques (Amazon Alexa, Google Home, Huawei HiLink, etc.). Prises contrôlées, relais Wi-Fi, thermostats d'ambiance, mesureurs de consommation, chargeurs USB... La gamme est grande et la plupart de ces périphériques présentent un intérêt tout particulier pour nous : ils intègrent un microcontrôleur Espressif Systems qu'il est possible de reprogrammer.

Le modèle le plus basique, et le plus économique est le Sonoff Basic R2 (v1.3). Vous le trouverez dans toutes les crèmeries habituelles pour une poignée d'euros (dont des packs de 10 sur Amazon pour ~75 € [13] si vous êtes pressé, ou à ~60 € sur AliExpress [14] si vous aimez attendre). Celui-ci se présente sous la forme d'un petit boîtier blanc de 9 cm de long, 4 cm de large et 3 cm de haut, avec un bornier phase/neutre d'un côté en entrée et un autre, de l'autre côté, en sortie. Remarquez l'absence de broche pour la terre et la limitation à 10 A, en faisant clairement un périphérique qu'on essayera de limiter au contrôle de luminaires (ne branchez pas un four ou un lave-linge là-dessus !).

Mais le plus intéressant se trouve à l'intérieur du produit, car celui-ci est géré par un ESP8285. Si ce nom ne vous dit rien, il s'agit simplement d'une déclinaison de l'ESP8266, fortement intégré, ayant les mêmes caractéristiques et embarquant, dans la puce, 1 Mo de flash. Mieux encore, le circuit dispose d'un emplacement (libellé en plus) permettant de souder un connecteur standard au pas de 2,54 mm permettant de connecter un adaptateur USB/série et donc de programmer facilement la flash. Le connecteur soudé pourra d'ailleurs rester en place puisqu'il n'interfère pas avec la fermeture du boîtier.

Adapter les Sonoff Basic R2 à nos besoins revient à simplement :

• tous les démonter (c'est facile, c'est simplement clipsé) ;
• souder un connecteur ;
• connecter l'adaptateur USB/série fournissant également l'alimentation 3,3 V (ne branchez pas le Sonoff au 230 V !) ;
• flasher le firmware ESPHome ;
• en profiter pour noter l'adresse MAC de l'ESP8285 au feutre indélébile sur la partie inférieure du boîtier ;
• et réassembler le tout.

La configuration du firmware est relativement simple et je vous ferai grâce de répéter la procédure avec le wizard pour entrer directement dans le vif du sujet. Voici donc la configuration YAML utilisée :

Nous avons ici trois éléments :

• une entrée correspondant au bouton présent sur l'appareil et connectée au GPIO0 (celui-là même servant à passer l'ESP8285 en mode programmation, cf. plus loin) ;
• une première sortie correspondant au GPIO12 connectée au transistor contrôlant le relais ;
• et une seconde sur GPIO13 permettant le contrôle de la LED bleue (il s'agit d'une LED bicolore rouge/bleue, avec la partie rouge directement reliée à l'état du relais).

Remarquez comme ESPHome permet une certaine forme d'automatisation, même sans Home Assistant. Ici, nous avons un élément avec l'ID relay, de type switch qui est contrôlable par HA, mais également par l'état du bouton de type binary_sensor. La directive on_press permet d'activer une bascule sur l'état du relais et donc de permettre de manuellement activer/désactiver le composant par une simple pression sur le bouton. Bien entendu, cette configuration n'est en rien une obligation, mais la position du bouton dans le boîtier n'offre pas réellement d'autre possibilité d'utilisation. Ceci dit, rien ne vous empêche de commencer à modifier le périphérique et son circuit pour détourner l'utilisation des GPIO reliés à la LED et/ou au bouton. Mais ceci dépasse le cadre du présent article (et nous avons encore beaucoup d'autres choses à voir).

Étant donné que le bouton est connecté à GPIO0 (alias IO0) et connecte l'entrée à la masse lors d'une pression, c'est également celui-ci qui contrôle le passage en mode programmation. Pour flasher le Sonoff, maintenez donc simplement le bouton enfoncé en connectant l'adaptateur USB/série et celui-ci démarrera dans le bon mode. Vous pourrez ensuite utiliser Docker comme précédemment pour générer le firmware et le charger en flash :

Et, pour les exemplaires suivants :

avec ici sonoff2 comme nom d'appareil changeant à chaque fois. Et si vous êtes comme moi, vous en avez certainement au moins encore 9 autres à flasher.

L'intégration dans Home Assistant se fera exactement comme pour la ou les ESP32Cam. Dès la mise sous tension, les Sonoff reflashés avec ESPHome seront détectés et s'ajouteront alors à votre installation domotique après authentification et avoir été placés dans une pièce. À l'instar de la LED blanche d'un ESP32Cam, une entité « switch » sera disponible et aura pris place sur votre tableau de bord généré automatiquement. Mais ces Sonoff s'accompagnent d'une seconde entité, « binary_sensor », qui est également présente, correspondant au bouton de l'appareil. Quelque part, vous venez donc également d'ajouter votre premier capteur à HA.

3.6 Capteurs de température ESP-01

Voici qui nous permet de faire un magnifique enchaînement, puisqu'il est enfin temps de parler de ce que je considère comme l'élément le plus intéressant ici : les capteurs. Même si contrôler différents appareils depuis une interface web comme Lovelace est relativement amusant, ce n'est rien en comparaison avec la possibilité d'avoir une vue en temps réel d'un ensemble de mesures concernant son habitat.

La température est sans doute la donnée la plus courante à relever, mais celle-ci ne se limite pas nécessairement à quelque chose d'aussi basique que l'environnement d'une pièce à vivre. Il peut également s'agir de la température d'un ballon d'eau chaude, d'une cheminée, du circuit d'eau pour des radiateurs en différents points de l'installation, du sol dans le jardin, d'un compost, etc.

Pour cette partie, nous allons recycler et viser la solution la plus économique possible. Il y a fort longtemps (numéro 7 en 2015 [15]), nous avons fait connaissance avec l'ESP01. Une version réduite au strict minimum d'un module ESP8266 qui nous a servi à plusieurs reprises, dont une pour la création de capteurs de température combinant un bloc d'alimentation USB, un régulateur de tension et un ESP01 (dans le numéro 8 [16]). Nous pouvons réutiliser ce projet de près de 7 ans (déjà ?!) et, tout simplement, flasher un firmware ESPHome dessus pour l'intégrer à notre système domotique tout neuf.

La programmation des ESP01 est quelque peu délicate dans le sens où ces modules ne disposent d'absolument aucune interface de programmation ou de communication. Il est donc nécessaire de créer un montage pour les programmer, via un adaptateur USB/série, mais aussi quelques composants passifs. Le schéma de branchement est le même qu'à l'époque :

Le capteur dont il était question dans le numéro 8 reposait sur l'utilisation d'un composant Dallas DS18B20 (embarqué dans une capsule métallique étanche au bout d'un câble de 1 m). Celui-ci est interfacé en 1-Wire et est connecté au GPIO2 de l'ESP01 (seul disponible si on se réserve GPIO0 pour le mode programmation). Le DS18B20 n'utilise qu'une broche (DQ) pour communiquer (en plus de Vcc et de la masse) et il est nécessaire de placer une résistance de rappel à Vcc de 4,7 kOhms. Le tout est simplement relié à GPIO2, comme le précisera notre configuration YAML (esp01temp.yaml) :

Inutile de revenir sur le contenu de ce fichier qui est maintenant, je l'espère, parfaitement compréhensible par lui-même. Nous utiliserons, ensuite, la même commande Docker que précédemment et je ne vous ferai pas l'insulte de la répéter (ni sa déclinaison pour passer une valeur à devicename). La programmation en série est un peu pénible, du fait de devoir utiliser un montage dédié, mais c'est sans doute la version la moins chère pour obtenir rapidement des capteurs environnementaux, et aussi probablement la moins fiable, surtout en couplant cela avec un adaptateur secteur chinois le moins cher de la planète (j'ai régulièrement des déconnexions avec ces modules, alors que le problème ne se pose pas avec les Wemos D1 Mini ou les ESP32 DevKit).

Comme précédemment, à chaque mise sous tension post-programmation, les capteurs sont détectés par HA et intégrés sans le moindre problème, et viendront naturellement embellir votre tableau de bord (qui à ce stade ne sera sans doute plus automatique et, au contraire, fortement personnalisé) :

3.7 Un peu plus loin avec un Wemos D1 Mini : multicapteurs

Recycler les vieux ESP01 était bien amusant, mais les limitations sont importantes et il est bien plus efficace d'investir quelques euros de plus (~2 € pièce) pour reposer sur une plateforme plus capable comme un Wemos D1 Mini (ou un clone). Là, nous aurons une sélection de GPIO plus importante à notre disposition et pourrons créer des montages capables de supporter plusieurs capteurs.

Pour illustrer cela, je vais me tourner vers Tatiana, ma chaudière (oui, je donne des noms aux choses, Roger le four, Mireille la grenouille pour le lingue sale, Bob le frigo, etc.). Je chauffe encore au fioul puisque c'est ainsi que la maison m'a été vendue et qu'avec de bons réglages, c'est une solution somme toute viable (pour l'instant). Je ne suis pas chauffagiste, mais je sais que la température de l'eau circulant dans les radiateurs est un facteur important de la consommation de carburant et que le principe même de ce type de chauffage est de transférer les calories thermiques de l'eau, au travers des radiateurs, à l'environnement habitable. En cela, l'eau qui revient à la chaudière dans le circuit fermé doit s'être vue délestée de sa chaleur et une trop petite différence de température signifierait une efficacité réduite.

L'idée est donc d'attacher fermement deux capteurs DS18B20 directement sur les tuyaux et d'accompagner cela d'un second capteur BMP180 combinant pression atmosphérique (pourquoi pas) et température. Ce dernier est interfacé en i2c et nous nous retrouvons donc avec une problématique intéressante : comment à l'aide d'un unique Wemos D2 Mini arriver à lire deux DS18B20 et un BMP180.

Le BMP180 n'est pas un problème, puisque l'ESP8266 du Wemos sait parfaitement gérer cela, par défaut, via les broches D1/GPIO5 pour SCL (l'horloge) et D2/GPIO4 pour SDA (les données). Mais pour les deux DS18B20, deux solutions peuvent être envisagées : brancher les deux composants sur deux GPIO différents et donc utiliser deux bus 1-Wire, ou les connecter ensemble sur un unique GPIO (GPIO2 comme précédemment). La première option semble la plus facile puisque nous pouvons identifier facilement quel DS18B20 est où, mais la seconde permettant d'économiser un GPIO, c'est donc celle-ci que nous allons choisir.

Comme précédemment, quelques composants passifs sont nécessaires. Nous avons tout d'abord besoin d'une résistance de 4,7 kOhms entre DQ, la ligne de données des DS18B20, et la tension d'alimentation (Vcc). De telles résistances de rappel à Vcc sont également nécessaires pour SCL et SDA en ce qui concerne le bus i2c et le BMP180. Notez que cela peut parfaitement fonctionner sans, en particulier lorsqu'un seul capteur est présent sur le bus, mais mieux vaut faire les choses correctement (on ne sait jamais à quel point on va étendre le montage par la suite).

Côté configuration avec ESPHome, nous allons devoir procéder en deux étapes. Tout d'abord, nous allons créer une configuration minimale nous permettant de voir ce que l'ESP8266 détecte effectivement (d1temp2press.yaml) :

Notez que nous n'avons ici ajouté aucun capteur (sensor), mais que la section logger s'est vu complétée d'une ligne level: DEBUG afin de nous permettre d'obtenir un maximum d'informations dans la sortie du moniteur série. Nous compilons et flashons le firmware comme précédemment et voyons effectivement apparaître à l'écran :

Les lignes sont préfixées de [D] pour debug et nous obtenons les adresses des deux DS18B20. Nous pouvons alors compléter la configuration pour les intégrer et faire de même pour le BMP180 :

L'étape suivante sera ensuite d'identifier lequel des deux DS18B20 est out et lequel est in. Sans déconnecter le moniteur, ni intégrer le périphérique à Home Assistant, il suffit de se munir d'un verre d'eau chaude et d'y tremper l'un des capteurs, tout en observant la variation de mesure à l'écran (qui précise le nom de chaque composant). Ceci fait, on reportera l'information physiquement sur le montage (simple sticker ou marquage sur le câble du DS18B20) avant installation définitive.

Si, par la suite, vous avez l'intention d'ajouter un ou des DS18B20 supplémentaires, ceci est parfaitement possible. Ça a été mon cas, puisque la chaudière fioul est non seulement en charge des radiateurs en fonte, mais également de l'eau chaude sanitaire via un ballon situé non loin. Le thermostat du salon (qui est un montage que nous avons vu dans le numéro 32 [17]) ne fait que piloter le circulateur, mais même en l'absence de consigne de chauffe, la chaudière maintient la température du ballon. Deux capteurs sont donc insuffisants pour avoir une idée précise de ce qui se passe et j'ai donc ajouté, ensuite, un DS18B20 supplémentaire au niveau du circulateur :

En laissant tourner tout cela quelque temps, nous pouvons avoir une vision plus ou moins claire du comportement du système en question :

Les oscillations récurrentes de la température de sortie ainsi que celle du circulateur semblent correspondre aux périodes de chauffe des radiateurs, alors que les pics intermédiaires de montée en température sont sans doute associés au maintien de la température de l'eau sanitaire (ballon). Il semblerait qu'une bonne partie du fioul brûlé soit utilisée pour cet usage et il sera peut-être judicieux de remplacer ce ballon par un modèle supportant à la fois un mode de fonctionnement identique, mais également une chauffe électrique, offrant ainsi une alternative en fonction du coût des deux sources d'énergie. L'ajout d'un débitmètre sur l'arrivée de carburant peut également être une option intéressante pour permettre une analyse plus poussée, même si le fonctionnement d'une chaudière fioul rend cela assez délicat. Une autre solution, sans doute plus simple, serait de mesurer le volume de fioul dans la cuve et d’en déduire la consommation.

3.8 Capteurs de mouvement

Passons à quelque chose de plus en lien avec les personnes et leurs activités. Vous connaissez sans doute ces produits intégrant un capteur de mouvement. Généralement, il s'agit de solution d'éclairage se mettant automatiquement en marche lorsqu'un mouvement est détecté. Lorsqu'il s'agit d'installation extérieure, le système est souvent couplé avec une détection de luminosité ambiante (LDR) permettant de limiter l'activation à la nuit tombée.

Ce type de produits utilise généralement un capteur infrarouge ou PIR (pour Passive InfraRed) qu'il est parfaitement possible de trouver sous la forme de modules indépendants, relativement simples et peu chers. Il existe différents modèles, certains configurables, d'autres non, mais tous ont généralement en commun trois broches : une pour la masse, une pour l'alimentation (3,3 V à 5 V) et une nommée trigger indiquant un déclenchement et donc une détection. Cette sortie est celle pouvant être utilisée avec un microcontrôleur, comme un ESP8266.

Mon modèle préféré de capteur PIR est le HC-SR505. Il n'est pas configurable du point de vue de son mode de déclenchement, ou de sa sensibilité et n'est pas capable de piloter directement un MOSFET ou un relais (sauf à ajouter des composants externes), mais il est très compact (3 cm de long pour 1 de large). Il présente en sortie les classiques broches que je viens de détailler, et rien de plus. La documentation [18] indique une tension d'alimentation entre 4,5 V et 20 V, mais des niveaux logiques 3,3 V/0 V, ce qui est parfait pour un ESP8266. Le délai par défaut après déclenchement est de 8 secondes et l'angle de vue pour la détection est de 100°, avec un récepteur équipé d'une lentille de 10 mm.

Mon objectif ici est de me pencher sur la problématique de l'entrée de la maison, qui n'est pas directe. Une pièce intermédiaire, d'environ 1 m², se trouve juste derrière la porte principale et donne accès au couloir/palier du rez-de-chaussée. Cette zone ne possède aucune fenêtre ou source naturelle de lumière et, pour l'heure, utilise un capteur PIR directement monté sur la douille de l'ampoule au plafond. Installer un montage ici a pour objectif premier de faire exactement la même chose que ce qui est présentement en place : allumer la lumière. Des interrupteurs « intelligents » Sonoff T4EU1C (ne nécessitant pas de fil neutre dans les emplacements muraux) sont commandés et arriveront sous peu (~15 j). Ils fonctionnent exactement de la même manière que les Sonoff Basic R2 et peuvent, bien entendu, être reflashés avec un firmware ESPHome (bien que la technique soit plus subtile qu'avec les Basic R2 [19] du fait de l'utilisation d'un bouton capacitif sur GPIO0).

La raison de l'utilisation d'un montage complexe et d'un pilotage d'un interrupteur Sonoff tient dans le fait de pouvoir à la fois détecter l'arrivée d'une personne (ou le départ), mais également de rendre d'autres choses automatisables (comme l'éclairage temporaire d'une autre partie du rez-de-chaussée). Mais ça, ce sera pour plus tard. En attendant, c'est une belle excuse pour voir la façon d'ajouter un capteur PIR à HA via ESPHome. Bien entendu, comme un Wemos D1 Mini est à l’œuvre, autant en profiter pour ajouter un DS18B20 et relever la température de la pièce la plus froide de la maison (à l'exception des w.c. du RDC, mais au moins on y reste pas longtemps), puisqu’exposée plein nord et prompte à laisser entrer le froid.

Notre configuration, wemosPIRtemp.yaml, et c'est là la surprise, sera composée presque entièrement d'éléments que nous connaissons déjà :

Cette fois, le bus 1-Wire sera connecté à la broche D1/GPIO5 du Wemos D1 Mini (avec toujours une résistance de rappel à Vcc de 4,7 kOhms) et le module PIR sera branché à D2/GPIO4, sous la forme d'un binary_sensor, exactement comme le bouton du Sonoff Basic R2. Notez cependant la mention de la classe motion destinée à faciliter l'intégration dans Home Assistant.

À ce propos et juste après l'intégration, identiques aux précédentes, vous trouverez dans votre HA un appareil « wemospirtemp » avec deux entités : « sensor.wemospirtemp_temperature » et « binary_sensor.entree_pir » :

Cette dernière peut servir pour un petit test rapide, sans avoir à écrire la moindre ligne de code. Ceci est rendu possible grâce à l'utilisation de blueprints qui sont, comme le nom l'indique, des « plans » pour créer des automatisations. Le blueprint qui nous intéresse ici est « Motion-activated Light ». Vous le trouverez en vous rendant dans « Paramètres », « Automatisations et scènes » et onglet « Blueprints ». Mais avant cela, nous devons changer le type de l'entité que nous souhaitons utiliser. En effet, nos Sonoff Basic R2, et plus précisément le contrôle du relais qui s'y trouve a été configuré comme des interrupteurs (switch), mais le blueprint, par défaut, est prévu pour contrôler des lumières (lights) et ne verra donc pas cette entité du Sonoff.

Pour ajuster rapidement cela, rendez-vous dans la liste des entités et repérez celle qui nous intéresse. Cliquez dessus et à la ligne « Afficher en tant que », choisissez « Lumière ». HA vous précisera quelque chose d'important qui dénote la manière de fonctionner du système. L'entité provient de notre configuration ESPHome et donc du firmware embarqué qui ne peut pas changer (sauf reflashage). HA ne va donc pas réellement changer le type, mais créera une copie de l'entité en question, avec le nouveau type et cachera l'ancienne, qui reste utilisable et utilisée sur les tableaux de bord déjà existants. Si vous souhaitez revenir en arrière, suite au test, aucun problème, supprimez simplement la nouvelle entité et l'ancienne repassera automatiquement de l'état « Cachée » à « Activée ».

Une fois l'entité de test réglée sur le bon type, allez dans « Paramètres », « Automatisations et scènes », « Blueprints » et cliquez sur « Créer une automation » à la ligne « Motion-activated Light ». Vous serez alors invité à choisir :

• un capteur (« Motion Sensor »), ici « Entree PIR » ;
• une lumière à contrôler (« Light »), ici une entité « sonoff1 Basic Relais » ;
• et un délai en secondes (« Wait time ») correspondant à la durée durant laquelle la lumière doit rester allumée en l'absence de détection de mouvement (les 8 s fixées physiquement par le module PIR n'ont donc plus aucune importance).

Réglez tout cela et enregistrez. On vous demandera de spécifier un nom pour cette automatisation et, éventuellement, une petite description. Et voilà, votre première automatisation est prête, vous n'avez plus qu'à vous agiter devant le capteur PIR pour en vérifier le fonctionnement (ne vous inquiétez pas, personne ne vous verra). Et, bien sûr, cela fonctionne sans problème.

Un blueprint n'est pas un générateur de scripts, mais un modèle réutilisable et configurable. Vous n'obtiendrez donc pas un YAML qui puisse être indépendant du blueprint. Si vous êtes curieux comme moi, peut-être souhaiterez-vous voir à quoi ressemble ce blueprint. Il se trouve dans ~/config/blueprints/automation/homeassistant, sous le nom motion_light.yaml, et effectivement, il ne fonctionne qu'avec des light :

Votre automatisation, quant à elle, se trouve directement dans ~/config (qui est un lien symbolique vers /config), dans le fichier automations.yaml :

C'est d'ailleurs à cet endroit que s'ajouteront, au fur et à mesure, les autres automatisations que vous allez créer et, je l'espère, finirez directement par écrire en YAML (d'où l'intérêt de disposer d'un accès SSH).

3.9 Et les radiations alors ?

Voilà quelque chose qui paraissait simple au départ, mais s'est avéré relativement épineux. Non pour la mesure en elle-même, puisque c'est là quelque chose que nous avons exploré dans un précédent numéro (Hackable 30 [20]), mais en raison de difficultés techniques qui ont été réglées, mais non totalement élucidées.

Un compteur Geiger-Müller est, en soi, relativement simple : on présente une tension importante aux extrémités du tube (entre 360 et 440 volts pour un tube russe STS-5 détectant les rayonnements gamma et X) et lorsqu'une particule ou un rayonnement ionisant le traversent, celui-ci devient brièvement conducteur. Lorsqu'on branche un amplificateur et un haut-parleur (buzzer), le signal correspondant se transforme en crépitement audible caractéristique de ce genre d'appareil. Dans un précédent numéro, nous avions utilisé, entre autres choses, un kit qui est étonnamment toujours en vente [21] et celui-ci est donc sorti de son placard.

Ce montage s'utilise normalement avec une carte microcontrôleur de type Arduino et l'interface est relativement simple puisqu'en dehors de l'alimentation 5 V et la masse, le signal est simplement transmis tel quel. Il suffit alors de compter les passages à l'état bas pour mesurer le nombre de CPM (Counts Per Minute) et éventuellement en déduire l'exposition (à condition de parfaitement connaître les caractéristiques du matériel, ce qui est loin d'être le cas avec un simple kit).

La difficulté a ici été de compter effectivement ces impulsions qui devraient durer 10 µs, mais en réalité, dans les faits, ne font que 1,5 µs (composant défectueux ?). Après plusieurs heures d'analyse et de recherches, et aidé d'un oscilloscope, il s'avère apparemment qu'un ESP8266 est bien incapable de détecter une impulsion aussi courte (ou alors est-ce le fait de capacités parasites internes aux Wemos D2 Mini ?). Il m'a donc fallu me rabattre sur quelque chose de plus vif et donc un DevKit ESP32, qui lui, a fonctionné du premier coup sans le moindre problème.

La configuration YAML correspondante est la suivante :

Un nouveau capteur est ici utilisé, pulse_counter, qui comme son nom l'indique est un compteur de pulsations (généralement utilisé pour les compteurs électriques ou d'eau par exemple). Plusieurs lignes sont importantes ici, dont internal_filter, qui m'a fait perdre un temps phénoménal. En effet, par défaut et pour éviter les comptages erronés avec des appareils électromécaniques, toutes les impulsions de moins de 13 µs sont simplement ignorées. Nous devons donc impérativement réduire cette valeur pour obtenir le moindre signal du kit compteur. Autre élément important, count_mode nous permet de spécifier ce que nous comptons avec ici, les flancs montants qui sont ignorés et les flancs descendants qui incrémentent le compteur. Enfin, pour mitiger le bruit de fond, nous déduisons 12 à la valeur mesurée avant envoi à Home Assistant.

Une fois l'ESP32 flashé comme d'habitude, nous pouvons intégrer une nouvelle mesure à notre tableau de bord, cette fois sous la forme d'une jolie jauge :

4. Un peu d'automatisation tout de même

Nous n'entrerons pas grandement dans le détail ici faute de place, mais aussi parce que ce sujet mérite un article, presque tout aussi massif que celui-ci, à lui tout seul. Mais nous avons cependant un problème à régler concernant notre détecteur PIR et l'allumage de la lumière. L'utilisation de blueprints est intéressante (encore un autre article à écrire), mais mieux vaut apprendre à scripter ses automatisations soi-même et, fort heureusement Lovelace peut nous y aider.

Rendez-vous dans « Paramètres », « Automatisations et scènes » et cliquez sur « Créer une automatisation ». Dans le popup qui s'affiche, choisissez « Commencer par une automatisation vide » et on vous présentera alors une interface graphique vos permettant de produire des scripts simples. Une automatisation repose sur trois éléments :

• un déclencheur ;
• une ou plusieurs conditions à valider ;
• et une action à mener.

Dans notre cas, le déclencheur sera un état et plus exactement celui de l'entité correspondant au capteur PIR, passant à « Détecté ». Ignorons les conditions puisque le déclencheur nous suffit ici, même si nous pourrions vouloir imposer des heures de prise en compte ou encore n'agir qu'en fonction de l'état d'une autre entité. Dans les actions, nous voulons appeler un service (voyez cela comme une méthode sur un objet ou un appel de fonction), ce sera « Commutateur: Turn on » et nous spécifierons l'entité ciblée, ici le relais de notre quatrième Sonoff. Enregistrez cette automatisation en lui donnant un nom. Celle-ci est automatiquement ajoutée dans la liste et activée. Bougez devant le capteur PIR et voici que la lampe branchée sur le Sonoff en question s'allume !

Si vous êtes comme moi, ces menus, ces désignations « franglaises » et ces formulaires web, bien que fort jolis, ne vous séduiront pas outre mesure. Voyons à quoi ressemble le code de ce que nous venons de faire. Retournez dans l'automatisation que vous venez de créer, cliquez en haut à droite sur les trois petits points et choisissez « Modifier en tant que YAML ». Vous découvrirez alors ceci :

C'est votre automatisation, telle que HA l'aura écrite pour vous. Nous pouvons, tout d'abord, la simplifier, éliminer ce qui ne sert à rien, et raccourcir un peu tout cela :

Voilà qui est plus simple et tout aussi fonctionnel. Nous retrouvons les différents éléments spécifiés, mais désignés par leur nom réel : si le state de binary_sensor.entree_pir devient on, alors on appelle switch.turn_on sur switch.sonoff4_basic_relais. Limpide !

Mais... comment éteint-on la lumière maintenant ? C'est simple, on ajoute une automatisation :

Toute la logique est inversée, mais nous avons ajouté notre grain de sel avec la ligne for permettant de temporiser la réaction au déclencheur. Ici, nous attendons que le capteur PIR soir désactivé pendant 30 secondes, et là seulement, nous appelons switch.turn_off sur notre Sonoff.

Et voilà comment nous pouvons automatiser tout et n'importe quoi dans Home Assistant. Pour en apprendre davantage, explorez le contenu de la section « Outils de développement » de l'interface Lovelace. Et en particulier, l'onglet « Etats » pour connaître l'état de toutes vos entités présentes, ainsi que « Services » pour faire connaissance avec tout ce qu'on peut demander à HA et aux entités.

Notez que ce que nous venons de voir n'est qu'une façon de faire parmi tant d'autres, car les automatisations et leurs descriptions YAML sont presque un véritable langage de programmation. Un bon point de départ pour découvrir le domaine est le cookbook Home Assistant [22] qui regroupe des dizaines d'exemples très instructifs.

5. Plan de masse

Si vous avez commencé à jouer avec les tableaux de bord et pris en main la logique un peu particulière du placement des éléments (appelée « cartes »), vous avez sans doute également commencé à trier vos petites affaires selon vos préférences. Personnellement, après quelques essais et erreurs, je me suis arrêté sur une organisation divisée en trois grands tableaux :

• « Contrôle » pour piloter les lumières, les interrupteurs et autres ;
• « Environnement » pour tout ce qui concerne les mesures et les températures en particulier (des pièces ou des éléments de chaudière) ;
• et « Cam » pour avoir un aperçu rapide des différentes caméras installées.

Mais il est une chose que j'ai toujours rêvé d'avoir dans une installation domotique comme celle-ci : un plan complet de mon habitation, étoffée de différentes informations environnementales et de contrôles me permettant de piloter les périphériques « domotisés ». Ce n'est pas forcément très ergonomique, mais le facteur « Wow » est très important. Notez qu'habituellement, la plupart des utilisateurs optent pour une représentation assez moderne de leur habitat en utilisant une image issue d'une application en logiciel libre comme Sweethome3D [23]. Personnellement, je préfère quelque chose de plus « oldschool » en forçant le trait sur le côté « vintage » années 80 (plan du dessus, en couleurs inversées et avec une teinte verte). Mais peu importe l'aspect graphique et artistique, le processus sera le même.

La pièce maîtresse de ce type de représentation est la carte « Éléments d'image », sur un tableau ayant une vue de type « Panneau » où une carte occupe tout l'espace disponible à elle seule. L'interface de configuration n'est pas aussi « graphique » que la plupart des autres cartes et c'est peut-être justement là que se trouve la raison de l'absence de tutoriels complets sur le sujet. Oui, pour arriver à obtenir le résultat escompté, il faudra faire du YAML, beaucoup de YAML...

En ajoutant la carte au tableau, voici ce que vous aurez sous les yeux :

Nous avons ici un picture-elements contenant un unique élément de démonstration (le niveau de batterie de mon smartphone A40), qui est un state-badge présentant une icône d'état, placé à 32% du haut de l'image et à 40% du bord gauche de cette dernière. Image qui est spécifiée à la dernière ligne est, là encore, est une simple illustration de démonstration.

C'est le premier point auquel il faudra s'attaquer et ceci nécessitera un peu d'efforts. L'image, ou les images si vous comptez faire un tableau par étage, devront être stockées quelque part et plus exactement, quelque part sur la Pi nous servant d'hôte pour le système. Home Assistant est capable de servir des médias et fichiers statiques, comme le ferait n'importe quel serveur web. Ceux-ci doivent être placés dans un répertoire spécifique et sont alors accessibles via l'URL http://http://homeassistant.local:8123/local, où « homeassistant » est le nom d'hôte du système et « homeassistant.local » le FQDN (Fully Qualified Domain Name) mDNS résultant. Bien évidemment, les médias sont alors également accessibles depuis HA lui-même, en spécifiant simplement local/ suivi du reste de l'arborescence utilisée.

L'emplacement où mettre les fichiers n'existe pas par défaut, vous devrez le créer. Il s'agit de /config/www et un simple accès SSH fera l'affaire pour cela. Nous créerons d'ailleurs directement /config/www/floorplan pour y placer nos images, via une copie avec scp. Notez que vous serez obligé de redémarrer Home Assistant pour que ce répertoire soit pris en compte (www/, pas le reste) : « Paramètre », « Système » et, en haut à droite « redémarrer » (j'ai cherché un bout de temps).

Je n'ai pas créé les plans de masse spécialement pour cette occasion et c'est aussi l'une des raisons qui m'ont poussé à adopter un design « rétro ». J'avais précédemment utilisé un service en ligne, ArchiFacile [24], permettant de créer relativement facilement des plans directement dans un navigateur. J'ai d'ailleurs fini par souscrire au service (unique paiement non récurrent de 37 €) fin 2018, tant l'outil est simple et pratique pour préparer sereinement un déménagement (non, je ne suis pas sponsorisé, mais je sais apprécier un bon service quand j'en trouve un).

Les quatre images, une par étage, ont été exportées de l'outil et retraitées avec le logiciel de retouche d'images Gimp : changement de dimensions (1526 x 772), désaturation, inversion des couleurs et colorisation (teinte +140 et luminosité -30 pour un beau vert « cathodique »). Après plusieurs essais, les quatre fichiers résultants, g2floorplan_rdc.png, g2floorplan_1er.png, g2floorplan_2eme.png et g2floorplan_ss.png, ont été copiés avec scp sur la Pi, dans /config/www/floorplan.

La dernière ligne du YAML devient alors (pour le premier tableau) :

La carte est une « Éléments d'image » ou picture-elements. Nous nous sommes occupés de l'image, il est temps de passer aux éléments. Chacun d'eux sera listé, en respectant la syntaxe YAML, dans la section elements:, précédé d’un tiret -. Je ne vais pas lister la configuration des quatre cartes/pièces, mais détailler un à un les différents éléments utilisés un peu partout, en insistant sur certaines spécificités. Si quelque chose ne vous semple pas clair, n'hésitez pas à vous précipiter sur la documentation officielle [25] détaillant les variables utilisables et les types d'éléments.

Commençons par quelque chose de simple, en positionnant tout d'abord, un interrupteur Sonoff Basic R2 :

Nous avons ici un élément state-icon destiné à représenter l'état d'une entité via un pictogramme. Ceci signifie donc que l'état allumé ou éteint d'un interrupteur impactera l'icône qui changera de couleur en fonction de son état. En d'autres termes, vous pourrez voir, d'un coup d’œil, ce qui est en fonction dans tout l'étage.

L’icône par défaut est celle associée au type d'entité (rappelez-vous notre petit changement lors de l'essai du capteur PIR), mais nous pouvons, avec icon, spécifier manuellement celle-ci. L'éditeur de code YAML est assez intelligent pour nous proposer des complétions automatiques, il suffit de débuter avec mid: et chercher dans la liste (longue). Nous avons également entity: qui désigne l'entité concernée et qui est un paramètre obligatoire. Nous retrouvons là l'un de nos Sonoff Basic R2 précédemment configuré. tap_action: et double_tap_action: précisent le comportement à adopter en cas de simple et de double clic. Dans le premier cas, nous basculons l'interrupteur, alternant donc entre allumé et éteint. Le double clic permet d'afficher les informations sur l'entité, dont l'historique d'activation. Enfin, style:, sur lequel nous allons revenir plus loin, permet, à minima de placer l'icône au bon endroit sur l'image.

Notez qu'une prévisualisation est rafraîchie automatiquement à la saisie, mais que la résolution est loin d'être suffisante pour un placement précis. Vous serez donc obligé de valider et d’éditer à plusieurs reprises pour placer parfaitement vos éléments.

Passons maintenant aux caméras :

On reconnaît des éléments connus et, en dehors du type, qui devient icon, rien de bien intéressant ne fait son apparition. Nous choisissons ici icon, car nous n'avons pas réellement d'état à présenter. Notre objectif est de simplement permettre l'affichage de l'image après un clic, ce qui correspond au comportement par défaut.

Plus intéressant maintenant, nous avons les températures :

Cette fois, nous utilisons un state-label destiné à représenter l'état d'une entité sous la forme de texte. Dans le cas d'un capteur de température, son état est tout simplement la valeur mesurée. Ainsi, la température apparaîtra à l'endroit précis où est situé le capteur (avec les bons top et left bien sûr). Plus délicat à trouver, le style indiquant la couleur du texte est une propriété CSS spécifiant comment doit être présenté cet élément. Nous ajustons ici l'épaisseur du trait (la graisse du texte) et sa couleur, sous la forme d'un nom standardisé (voir [26]). Il est ainsi possible d'ajuster énormément de réglages en termes d'affichage, mais ceci nécessitera de solides bases en HTML/CSS, tout en sachant que l'objectif n'est pas de faire une œuvre d'art, mais de rendre simplement tout cela lisible (comme en mettant de l'orange gras plutôt que du blanc maigre sur une page sombre à dominante verte).

Dans le même ordre d'idées, nous avons les températures liées au fonctionnement de la chaudière, avec quelques nuances :

Ici, la problématique concerne le sens des valeurs affichées, en particulier du fait qu'elles soient l'une contre l'autre en surimpression du dessin de la chaudière. Pour régler cela, nous utilisons non seulement des couleurs très franches (red et dodgerblue), mais nous ajoutons également un texte complémentaire après la valeur avec suffix. Une directive équivalent, prefix permet de spécifier le texte à placer avant la valeur.

Le résultat pour cet étage sera le suivant :

Conclusion et futur

Après ce gros tour d'horizon qui aura un peu débordé du week-end initialement prévu (mais c'est parce que je prenais des notes et rédigeais en même temps), je pense avoir une relative bonne maîtrise de l'installation. Et j'espère également, par la même occasion, vous avoir donné l'envie de, vous aussi, vous lancer dans l'aventure. Initialement dubitatif quant à la solution, je dois avouer que Home Assistant et ESPHome s'avèrent être très intéressants et, l'un comme l'autre, avoir le bon ton d'être à la fois accessibles à l'amateur éclairé, mais aussi à l'utilisateur souhaitant fouiller dans les coins et n'étant satisfait que lorsqu'il retrouve ses petites habitudes (dont l'isolation du Net et l'accès en ligne de commandes).

Je pense raisonnablement conserver cette solution, car elle semble parfaitement adaptée, même si le biais psychologique (escalade de l'engagement) joue forcément un rôle. Escalade qui d'ailleurs est loin d'être terminée, car il y a nombre de choses encore à ajouter. Citons par exemple le fait de mesurer automatiquement la quantité de fioul disponible dans la cuve (comprenez par là « sans utiliser une longue tige en aluminium pour mesurer le niveau »). Ceci peut être fait relativement facilement en utilisant un module sonar à ultrason [27], toute la difficulté résidant davantage dans le caractère extérieur de la mesure. Là, deux solutions : soit s'amuser à tirer un câble, soit miser sur le solaire avec quelque chose comme un LiPo Rider [28] ou quelque chose d'approchant. Dans les deux cas, le montage devra pouvoir résister aux éléments, qui sont peu cléments en Alsace.

À propos d'environnement extérieur, justement, le jardin semble être un terrain de jeu de prédilection pour étendre un projet domotique. On pense naturellement à l'irrigation, avec vannes et arroseurs, mais aussi au système de collecte d'eau de pluie et aux mesures d'humidité dans le sol. Le tout, de préférence solaire pour ce qui concerne le fonctionnement des capteurs, mais en ayant recours, au besoin, à une autre source d'alimentation en cas d'utilisation de pompes. J'avoue que, le printemps n'étant pas pour tout de suite, je n'ai pas structuré mentalement cette partie avec précision pour le moment.

Autre point qui est dépendant de facteurs externes, mais est un point crucial du futur système, le monitoring de la consommation électrique est une priorité. Il semblerait que le fournisseur d'électricité local, Vialis pour ne pas le nommer, soit en cours de déploiement de compteurs Linky auprès de ses clients. Je n'ai pour l'heure pas de nouvelles précises concernant ma propre installation, mais ce sera l'occasion de profiter des fonctionnalités qui accompagne ce changement, d'autant qu'un support existe déjà dans ESPHome [29]. Je n'ai personnellement pas de préjugés mystiques concernant cet équipement et je sais de source sûre que deux ou trois cristaux, judicieusement baignés dans de l'eau de pluie collectée une nuit de pleine lune, et un attrape-rêve en plumes de caribou annulent tous les effets néfastes de la 5G des chemtrails du compteur... Plus sérieusement, mieux vaut pour moi attendre et profiter gratuitement du nouveau système plutôt que d'investir dans des équipements de mesure utilisables immédiatement. Le seul reproche qu'on puisse faire à ce compteur nouvelle génération, et là je suis parfaitement sérieux, est son horrible couleur. Et dire que quelqu'un, quelque part, a été payé (grassement, si cela se trouve) pour faire ce choix...

Dans le même ordre d'idée, la surveillance de la consommation d'eau est aussi une problématique qui devra être réglée. Ceci demande des compétences en plomberie que je n'ai pas (et n'aurai peut-être jamais, aux vues de mes dernières tentatives dans le domaine), mais c'est une donnée télémétrique qui peut être très intéressante.

Bien entendu, remonter toutes ces données dans une installation domotique suppose une certaine nécessité de fiabilité. Là aussi, c'est une voie à explorer, car même si jusqu'alors mon habitat se portait à merveille sans tout cela, il y a fort à parier que cette installation risque de devenir essentielle. « Essentielle » est peut-être un bien grand mot, car rien ne sera structuré pour être réellement indispensable et donc être à la merci d'un quelconque problème. Cependant, il sera nécessaire de prévoir les sécurités d'usage, comme une politique de sauvegarde raisonnable et, pourquoi pas, étudier un mécanisme de redondance en cas de défaut. C'est un autre gros chantier qui fera certainement, le cas échéant, l'objet d'un article.

Au final, la conclusion de cette petite expérience est qu'il est relativement facile de « domotiser » avec une solution en logiciel libre, indépendante d'un constructeur ou d'un service de type cloud. Dans la pratique, la mise en œuvre est progressive et modulaire. On ajoute des briques petit à petit, au fil des envies et des besoins.

Les seules réelles difficultés sont, en fait, de trouver des alimentations (prises de courant) pour placer judicieusement les périphériques et, bien entendu, de faire preuve de retenue quant au nombre de sondes que l'on peut vouloir mettre en place. On se laisse, en effet, facilement prendre au jeu et on se surprend à vouloir relever des données aux endroits les plus incongrus comme... le nombre de chasses d'eau tirées, la variation de poids des litières des chats... Et je ne parle même pas de ce que j'appellerai le syndrome « Jacquouille la fripouille », se caractérisant par un besoin irrépressible de jouer avec les interrupteurs pilotés ou supervisés par Home Assistant, juste pour le plaisir de voir le tout fonctionner correctement...

Références

[1] https://connect.ed-diamond.com/hackable/hk-045/personnalisez-automatiquement-vos-installations-de-raspberry-pi-os

[2] https://play.google.com/store/apps/details?id=io.homeassistant.companion.android

[3] https://apps.apple.com/fr/app/home-assistant/id1099568401

[4] https://github.com/motioneye-project/motioneye

[5] https://motion-project.github.io/

[6] https://github.com/motioneye-project/motioneyeos/wiki/Supported-Devices

[7] https://connect.ed-diamond.com/Hackable/hk-026

[8] https://hub.docker.com/

[9] https://connect.ed-diamond.com/hackable/hk-041/utilisez-docker-pour-vos-environnements-de-developpement

[10] https://connect.ed-diamond.com/Hackable/hk-033/prise-en-main-de-l-esp32-cam

[11] https://esphome.io/components/esp32_camera.html

[12] https://esphome.io/guides/configuration-types.html

[13] https://www.amazon.fr/Cambani-Commutateur-Intelligent-Intelligente-Compatible/dp/B07N14C3TT

[14] https://fr.aliexpress.com/item/1005002368292569.html

[15] https://connect.ed-diamond.com/Hackable/hk-007/un-arduino-avec-wifi-pour-moins-de-10-euros

[16] https://connect.ed-diamond.com/Hackable/hk-008/assemblez-un-reseau-de-capteurs-de-temperature-sans-vous-ruiner

[17] https://connect.ed-diamond.com/Hackable/hk-032/vite-fait-creer-un-thermostat-d-ambiance-programmable

[18] https://static.rapidonline.com/pdf/78-4110_v1.pdf

[19] https://www.youtube.com/watch?v=RNQXRko5mPU

[20] https://connect.ed-diamond.com/Hackable/hk-030/detectez-la-radioactivite-mise-en-pratique

[21] https://www.rhelectronics.store/radiation-detector-geiger-counter-diy-kit-second-edition

[22] https://home-assistant-china.github.io/cookbook/

[23] http://www.sweethome3d.com/fr/

[24] https://www.archifacile.fr/

[25] https://www.home-assistant.io/dashboards/picture-elements/

[26] https://www.w3schools.com/colors/colors_names.asp

[27] https://esphome.io/components/sensor/ultrasonic.html

[28] https://connect.ed-diamond.com/Hackable/hk-010/lipo-rider-pro-l-autonomie-solaire-cle-en-main-pour-vos-projets

[29] https://esphome.io/components/sensor/teleinfo.html