Domotisation de notre maison

Chapitre 1 — Tout a commencé par un compteur

À la base, je n'avais pas spécialement décidé de domotiser la maison.

J'ai simplement reçu un courrier m'annonçant qu'on allait venir remplacer mon compteur électrique par un compteur communicant.

Évidemment, je ne pouvais pas juste me contenter de l'information.

Un compteur communicant, très bien. Mais qu'est-ce qu'il communique exactement ? À qui ? Comment ? Quelles informations sont disponibles ? Et surtout : est-ce que je peux y accéder moi-même ?

Quelques recherches plus tard, j'apprends qu'il est possible de consulter sa consommation électrique « en direct » depuis le site de l'opérateur de réseau.

« En direct » mérite quand même ses guillemets : les données peuvent avoir un retard d'au moins une quinzaine de minutes.

J'ai bien intégré l'information.

En continuant à creuser, je découvre quelque chose de nettement plus intéressant : le compteur dispose d'un port permettant, moyennant un petit dongle, de récupérer localement les données de consommation.

Et là, forcément...

Je veux ça.

Pas nécessairement parce que j'en ai besoin. Mais parce que la donnée est là, chez moi, produite par un appareil installé chez moi. Pouvoir y accéder directement, la conserver et la traiter comme bon me semble me paraît bien plus intéressant que de dépendre d'un service tiers, de son application et de ses limitations.

Et évidemment, ce qui devait être un simple remplacement de compteur ne s'est pas tout à fait déroulé comme prévu.

→ Un compteur communicant, un port P1 et quelques péripéties

Et puis il y a les panneaux solaires.

Disposer en temps réel de la consommation de la maison et de l'énergie injectée sur le réseau ouvre immédiatement quelques possibilités : pourquoi ne pas utiliser cette information pour piloter certains appareils en fonction de l'énergie disponible ?

À ce moment-là, cela n'avait pourtant pas énormément d'intérêt économique dans mon cas. Avec le mécanisme prosumer dont je bénéficiais encore, le réseau se comportait plus ou moins comme une gigantesque batterie virtuelle : ce que j'injectais compensait ce que je prélevais plus tard.

Mais ce mécanisme n'allait pas durer éternellement.

C'était donc une excellente excuse pour commencer à regarder comment tout cela fonctionnait et préparer la suite.

Il restait néanmoins un petit problème.

Si je commençais à récupérer les données du compteur, puis à ajouter des appareils capables de réagir à ces données, je n'avais aucune envie de me retrouver avec une collection d'applications propriétaires, chacune dépendante d'un fabricant ou d'un service dans le cloud.

Je voulais quelque chose que je puisse contrôler.

Quelque chose de local.

Quelque chose que je puisse modifier, connecter à autre chose et probablement casser de temps en temps.

Assez rapidement, Home Assistant s'est imposé comme une évidence.

Au départ, il s'agissait simplement de voir si je pouvais y récupérer les données du compteur et de quelques appareils. Évidemment, ça n'en est pas vraiment resté là.

→ Home Assistant ? C'est quoi ce truc ?

Et c'est à peu près à ce moment-là qu'une simple question sur un nouveau compteur électrique a commencé à se transformer en projet de domotisation de toute la maison.

Une chose en entraînant une autre...

Chapitre 2 — Et si on allumait une lampe ?

Quand on commence à parler de domotisation d'une maison, il ne faut généralement pas très longtemps avant que quelqu'un prononce le mot « lumière ».

Et forcément, je n'y ai pas échappé.

Ce n'était d'ailleurs pas complètement nouveau pour moi. J'avais beaucoup entendu parler de Philips Hue, essayé quelques ampoules connectées et nous avions déjà quelques luminaires commandables à distance de manière assez limitée.

Le principe était généralement le même : l'interrupteur servait toujours à allumer et éteindre la lumière, tandis que la variation, le changement de couleur ou les fonctions un peu plus évoluées passaient par une télécommande ou une application.

Ça fonctionnait.

Mais je n'ai jamais trouvé ça particulièrement convaincant. Entre les pertes de configuration, les réappairages occasionnels et le téléphone qu'il fallait sortir pour accéder à certaines fonctions, je n'avais jamais vraiment eu envie d'aller plus loin.

En revanche, tout cela m'avait donné une idée précise de ce que je voulais.

La solution devait être fiable, correctement intégrée à Home Assistant et ne pas demander une reconfiguration régulière. Si des mises à jour étaient nécessaires, pouvoir les gérer simplement — idéalement depuis Home Assistant — serait évidemment un plus.

Mais surtout, la maison devait continuer à fonctionner comme une maison.

Un interrupteur devait rester un interrupteur.

On appuie dessus, la lumière s'allume. Home Assistant disponible ou pas.

La domotique devait ajouter des possibilités, pas retirer celles qui existaient déjà.

Avec ces quelques critères en tête, j'ai commencé à regarder ce qui existait.

Et je suis rapidement tombé sur les petits modules Sonoff à installer derrière un interrupteur.

Compacts (en tout cas davantage que d'autres solutions que j'avais vues), plutôt abordables et bénéficiant d'avis globalement corrects, ils semblaient suffisamment intéressants pour tenter l'expérience.

Ils communiquaient en Zigbee.

Et ça, plutôt que de m'inquiéter, constituait même un argument en leur faveur.

J'avais déjà régulièrement entendu parler de Zigbee sans jamais avoir eu de raison particulière de m'y intéresser davantage. Mais l'idée d'utiliser un protocole spécifiquement conçu pour ce genre d'appareils me paraissait naturelle.

Si le projet devait un jour compter quelques dizaines de modules, capteurs et autres petits objets répartis dans la maison, je trouvais plus logique de leur consacrer un réseau adapté plutôt que de connecter tout ce petit monde directement au Wi-Fi.

Et puis Zigbee existait depuis suffisamment longtemps pour m'inspirer une certaine confiance.

Mon analyse extrêmement poussée a donc probablement ressemblé à quelque chose comme :

« Ça existe depuis un bon moment. Ça doit être mature. »

À bien y réfléchir, le choix du module Sonoff lui-même n'a probablement pas fait l'objet de beaucoup plus d'analyse.

Le format était intéressant, les retours semblaient corrects et le prix d'entrée était suffisamment faible pour que l'expérience ne coûte pas grand-chose si elle tournait court.

Je voyais surtout ça comme un mini-projet.

On en installe un, on voit comment ça fonctionne et, surtout, on voit si ça fonctionne bien.

Restait néanmoins à découvrir comment Home Assistant allait communiquer avec lui.

Et là, deux noms revenaient régulièrement : ZHA et Zigbee2MQTT.

Je voulais allumer une lampe et j'avais déjà une architecture à choisir.

→ ZHA ou Zigbee2MQTT ?

Une fois ce choix fait, il ne restait plus qu'à installer le premier module.

→ Installer un module Sonoff Zigbee derrière un interrupteur

L'intégration des premiers Sonoff s'est révélée un peu moins immédiate que prévu. Il fallait comprendre quelques subtilités de leur fonctionnement et de leur documentation.

Mais une fois celles-ci maîtrisées, l'opération est devenue relativement simple et surtout reproductible.

Quant à Zigbee, mon raisonnement approximatif ne s'est finalement pas trop mal vérifié : jusqu'à présent, il ne m'a pratiquement posé aucun problème.

Les périphériques restent connectés, le réseau fonctionne et je n'ai pas à m'en occuper.

Exactement ce que j'attends de ce genre de technologie.

Mes expériences ultérieures avec Thread et Matter seront... disons, un peu plus aventureuses.

Mais c'est une autre histoire.

Le petit projet « pour voir » était donc concluant.

Assez, en tout cas, pour que le premier module Sonoff ne reste pas longtemps tout seul.

Chapitre 3 — Techniquement possible

À ce stade, les choses commençaient plutôt bien.

Home Assistant fonctionnait, Zigbee s'était révélé étonnamment peu problématique et les premiers éclairages avaient été automatisés sans transformer la maison en un endroit où il fallait sortir son téléphone pour allumer une lampe.

Mais pouvoir commander un appareil depuis Home Assistant n'était finalement que la partie la plus visible de ce que je cherchais.

Appuyer sur un bouton dans une interface plutôt que sur celui qui se trouve au mur ou sur une télécommande, c'est pratique.

Ce n'est pas forcément de l'automatisation.

Ce qui devenait beaucoup plus intéressant, c'était de commencer à faire réagir la maison en fonction de ce qui se passait autour d'elle.

Et pour cela, nous avions deux candidats tout trouvés : les stores.

Nous avions déjà deux stores motorisés, pilotés par radio. L'objectif n'était pas simplement de pouvoir les ouvrir ou les fermer depuis Home Assistant, mais d'asservir leur fonctionnement à des informations dont Home Assistant disposait : l'heure, le jour de la semaine, la luminosité, la température extérieure...

Sur le papier, il ne manquait donc pas grand-chose.

Il « suffisait » de trouver comment leur parler.

Je savais que récupérer un signal radio, l'analyser et éventuellement le reproduire était techniquement possible. J'étais donc assez confiant : avec un peu de matériel, quelques recherches et du temps, il devait bien y avoir moyen d'intégrer proprement ces stores.

Ce qui devait être une petite intégration s'est progressivement transformé en exploration d'un protocole propriétaire bien plus sophistiqué que prévu.

J'aurais aimé trouver une solution élégante. J'étais même assez convaincu qu'elle existait.

Mais entre ce qui est techniquement possible et ce qu'il est raisonnable de faire pour ouvrir et fermer deux stores, mon optimisme allait subir un sérieux rappel à la réalité.

→ Deux stores, de l'AES et six relais plus tard

Au bout du compte, l'objectif était atteint : les stores pouvaient désormais faire partie des automatisations de la maison.

Mais j'en avais surtout retiré une première leçon assez concrète : en domotique, savoir qu'une chose est techniquement possible ne signifie pas nécessairement qu'il existe une manière simple, propre et raisonnable de la réaliser.

Parfois, il faut aussi savoir composer avec l'existant — et accepter que la solution finale ne soit pas celle qu'on avait imaginée au départ.

Heureusement, toutes les idées ne se transforment pas en exploration de protocoles propriétaires.

Certaines fonctionnent même presque exactement comme on les avait imaginées.

Un exemple tout simple : l'éclairage lorsque nous rentrons à la maison.

Home Assistant connaît la position de nos deux voitures. Lorsque l'une d'elles arrive à moins de 100 mètres de la maison, et que nous sommes à partir de quinze minutes avant le coucher du soleil, l'éclairage de l'allée s'allume pour sept minutes.

Une minute plus tard, c'est celui du hall d'entrée qui s'allume, lui aussi pour sept minutes.

Rien de particulièrement spectaculaire.

Mais lorsque nous rentrons le soir, l'allée est éclairée à notre arrivée et la maison nous attend avec le hall déjà allumé.

Il n'y a rien à faire, rien à demander et aucun bouton sur lequel appuyer.

Ce petit automatisme fera probablement l'objet d'un futur short. Il est simple, mais illustre bien ce que je cherchais à obtenir avec Home Assistant.

Pas nécessairement pouvoir tout commander depuis une interface.

Mais pouvoir prendre des informations provenant de systèmes qui n'avaient, au départ, pas grand-chose à voir les uns avec les autres — une voiture, l'heure du coucher du soleil, des éclairages — et les faire travailler ensemble pour obtenir un comportement adapté à notre usage.

Parfois, cela demande beaucoup plus d'efforts que prévu.

Et parfois, quelques règles suffisent pour que la maison fasse simplement ce qu'on aurait aimé qu'elle fasse.

Chapitre 4 — Et maintenant, Thread et Matter

Thread et Matter ne sont pas arrivés dans la maison simplement parce que j'avais décidé qu'il était temps d'essayer quelque chose de nouveau.

Comme souvent depuis le début de ce projet, il y avait un besoin beaucoup plus concret derrière tout ça.

Nous réfléchissions depuis quelque temps à l'installation d'une serrure connectée.

Après avoir regardé différentes possibilités, mon choix s'est finalement porté sur une Nuki Smart Lock Pro.

Je ne vais pas entrer ici dans les raisons de ce choix ni dans son installation — ce sera probablement l'objet d'un prochain short — mais le résultat nous a rapidement surpris.

La serrure fonctionne très bien avec son application et ses widgets. Surtout, ce qui pouvait facilement passer au départ pour un gadget s'est révélé beaucoup plus utile au quotidien que nous ne l'avions imaginé.

Évidemment, dès le départ, j'avais également prévu de l'intégrer à Home Assistant.

Et pour cela, plusieurs possibilités existaient.

Le Wi-Fi en faisait partie.

Thread et Matter aussi.

Ces deux voies permettaient d'arriver au résultat recherché, mais avec une différence qui m'intéressait particulièrement : le choix du protocole de communication avait un impact direct sur l'autonomie de la batterie de la serrure.

Thread devenait donc soudain beaucoup plus qu'une technologie intéressante à expérimenter.

Il y avait une vraie raison de l'utiliser.

Petit problème :

je n'avais pas de Thread Border Router.

En revanche...

j'avais des ESP.

Et notamment un ESP32-C6.

Celui-ci supporte Thread et, dans mon esprit, l'équation était donc simple : puisqu'il me fallait un Thread Border Router et que le C6 savait parler Thread, pourquoi ne pas en construire un avec ça ?

C'était en tout cas l'idée de départ.

Un de ces plans à la Hannibal Smith qui, sur le papier, ne pouvait évidemment que se dérouler sans accroc.

En creusant un peu, les choses se sont révélées moins directes.

Mon projet à un ESP allait finalement en nécessiter deux : le C6 pour assurer la communication avec le réseau Thread et un ESP32-S3 pour faire le lien avec le réseau IP de la maison.

Bon.

Le plan avait légèrement évolué.

Il ne restait plus qu'à faire fonctionner tout ce petit monde ensemble.

→ Construire un Thread Border Router avec deux ESP32

Et ça a fonctionné.

J'avais désormais mon propre réseau Thread et, surtout, une nouvelle possibilité d'intégration pour les appareils qui viendraient s'ajouter à la maison.

Zigbee n'avait rien fait de mal.

Il fonctionnait toujours aussi bien et il n'était absolument pas question de le remplacer.

Thread venait simplement s'ajouter à côté, parce qu'un appareil et un besoin concret avaient rendu son utilisation pertinente.

Et puisque j'avais maintenant un réseau Thread fonctionnel à la maison, c'était aussi une excellente excuse pour essayer quelques nouveaux jouets.

Un passage chez IKEA tombait justement assez bien.

Avec quelques capteurs et un interrupteur Thread/Matter, j'allais pouvoir me faire une première idée plus concrète de cette nouvelle génération d'appareils.

Sur le papier, la promesse est séduisante : un standard commun, des appareils de fabricants différents capables de fonctionner ensemble et un réseau Thread conçu précisément pour ce type d'usage.

Dans la pratique...

Disons que l'expérience a été un peu plus instructive que prévu.

→ Elle voulait juste un interrupteur

Rien de tout cela ne m'a donné envie d'abandonner Thread ou Matter.

Mais cela m'a rappelé quelque chose que Zigbee, après des années d'existence, m'avait presque fait oublier : entre une technologie prometteuse et une technologie devenue parfaitement banale à utiliser, il peut y avoir une période de transition assez... intéressante.

Et finalement, ce n'était pas vraiment un problème.

Zigbee continuait à faire son travail.

Thread et Matter venaient simplement s'ajouter aux possibilités.

C'est d'ailleurs quelque chose qui commence à devenir caractéristique de ce projet.

Je n'ai jamais vraiment décidé de construire une maison « Zigbee », « Thread », « Matter » ou quoi que ce soit d'autre.

Un besoin apparaît.

Je regarde les possibilités.

Et, de temps en temps, la réponse implique un ou deux ESP qui traînaient dans un tiroir.

---

Mise à jour

24/09/2026 — Ajout des chapitres 3 et 4, ainsi que quelques corrections mineures dans le texte.