Comment rendre Home Assistant plus fiable ?
La réponse courte, d’entrée de jeu : en traitant Home Assistant comme un cerveau, pas comme une moelle épinière. La logique de commutation de base (j’appuie sur le bouton, la lumière s’allume) descend dans les appareils ou se tend entre eux : automatisation ESPHome sur le microcontrôleur, binding Zigbee du bouton vers la lampe, association Z-Wave. Home Assistant garde tout ce qui demande vraiment un cerveau : le contexte, les scènes, les statistiques, le tableau de bord. Et quand le serveur est en train d’installer une mise à jour, de redémarrer ou tout simplement mort, la lumière de la douche s’allume quand même.
Voilà toute la thèse de ce billet. Le reste, c’est la justification, deux recettes concrètes et un tableau honnête de ce que chaque voie sait faire.
Pourquoi le sujet ne me lâche pas : Home Assistant a cessé depuis longtemps d’être un projet de bidouille pour devenir de l’infrastructure. Plus de 654 000 installations actives se déclarent volontairement aux statistiques du projet, et ce n’est que la part qui a accepté l’opt-in ; le chiffre réel est nettement au-dessus. Or l’infrastructure ne se juge pas à son tableau de bord. Elle se juge à l’interrupteur. Un interrupteur de 1975 affiche une disponibilité que n’importe quelle pile logicielle ne peut que contempler. Qui installe de la technique intelligente se mesure à ce niveau d’exigence, qu’il le veuille ou non.
Le goulot d’étranglement entre le bouton et la lampe
Déroulez au ralenti ce qui se passe dans une installation typique quand quelqu’un appuie sur un bouton Zigbee. Le bouton émet vers la clé coordinateur. La clé transmet la trame à Zigbee2MQTT. Zigbee2MQTT publie sur le broker MQTT. Home Assistant est abonné, une automatisation se déclenche, appelle light.turn_on, et la commande refait le même chemin en sens inverse : broker, Zigbee2MQTT, clé, radio, lampe.
Selon la façon de compter, cela fait sept stations pour « allume la lumière ». Chacune est un processus qui doit tourner. Chacune reçoit des mises à jour. Plusieurs se partagent la même carte SD, le même disque, le même petit ordinateur dans le couloir. Quand une station tombe, on ne perd pas une fonction de confort. On perd l’interrupteur. Ce que ça fait quand la panne arrive au pire moment, je l’ai raconté dans l’histoire de la cascade Z2M un jeudi après-midi — depuis, chaque automatisation que je construis passe par la question : que se passe-t-il quand cette chaîne casse ?
Soyons clairs : rien de tout cela n’est un reproche à Home Assistant. La pile est remarquablement stable, et la plupart de ces sept stations tournent des mois sans broncher. Mais stabilité et indépendance sont deux choses différentes. Une mise à jour reste une mise à jour, un redémarrage reste un redémarrage, et les deux font partie d’une exploitation honnête. La question n’est pas de savoir si le serveur s’absente un instant. La question est de savoir ce qui fonctionne encore à cet instant-là.
Cerveau et moelle épinière
Le corps humain a résolu ce problème avec élégance. Touchez une plaque de cuisson brûlante : l’arc réflexe retire la main avant même que le signal n’atteigne le cerveau. C’est la moelle qui décide. Le cerveau l’apprend juste après et peut s’occuper de la partie intéressante : jurer, analyser la cause, faire plus attention la prochaine fois.
C’est exactement cette répartition du travail que je veux dans une maison, parce qu’elle rend Home Assistant plus fiable sans rien lui enlever. Les réflexes (le bouton allume la lumière, l’interrupteur pilote le volet roulant) appartiennent à la couche la plus basse qui fonctionne encore : au microcontrôleur, au protocole radio, au besoin au bornier. Le cerveau fait le contexte : 20 pour cent de luminosité la nuit, volets baissés quand le soleil tape à l’ouest, chauffage coupé quand personne n’est là. Si le cerveau tombe, la maison perd son intelligence, mais pas sa fonction de base.
Mon test est simple : éteignez le serveur et faites le tour de la maison. Tout ce qui ne marche plus, mais qui de l’avis des habitants « doit toujours marcher », est posé sur la mauvaise couche.
Méthode 1 : ESPHome — l’automatisation habite sur la puce
La voie première et la plus radicale. Qui construit ses appareils avec ESPHome choisit où vit la logique : automatisation dans Home Assistant, ou automatisation dans le YAML de l’appareil lui-même. Pour les fonctions de base, la réponse est nette. Un bouton mural câblé physiquement sur le GPIO du contrôleur reçoit un on_press qui bascule directement le relais ou la lumière locale. Aucun réseau impliqué, aucune centrale consultée.
La documentation ESPHome est ici d’une franchise réjouissante. À la question de savoir si les automatisations fonctionnent sans connexion réseau, elle répond mot pour mot : « YES! All automations you define in ESPHome are executed on the microcontroller itself and will continue to work even if the Wi-Fi network is down ». Ce n’est pas un effet secondaire. C’est un objectif de conception.
Le plus beau : Home Assistant n’y perd rien. L’état du relais est toujours remonté dès que la connexion revient, le tableau de bord affiche la lumière correctement, et n’importe quelle automatisation HA peut commuter par-dessus — tamiser le soir, éteindre quand tout le monde part, ce que le contexte demande. Mais le bouton au mur fonctionne aussi quand Wi-Fi, broker et serveur se taisent tous en même temps. Je câble désormais chaque actionneur ESPHome pour que sa commande primaire soit locale, et je traite tout ce qui arrive de l’extérieur comme un bonus.
Méthode 2 : le binding Zigbee fait parler le bouton directement à la lampe
La deuxième voie ne demande pas de fer à souder. Zigbee embarque le pilotage direct d’appareil à appareil dans le protocole ; la fonction s’appelle binding. La documentation de Zigbee2MQTT le décrit exactement ainsi : les appareils se pilotent mutuellement, « without the intervention of Zigbee2MQTT ». Le bouton n’envoie pas sa commande au coordinateur pour traitement. Il l’envoie à travers le maillage vers la lampe liée. Serveur en plein redémarrage ? Zigbee2MQTT en pleine mise à jour ? La lampe s’en moque complètement.
En pratique, on lie rarement à une seule lampe, mais à un groupe Zigbee : le bouton de la salle de bain au groupe « salle de bain », et les trois spots réagissent d’un coup, avec une seule commande de groupe au lieu de trois messages individuels. Ce qui, au passage, soulage le réseau radio. Les utilisateurs de ZHA n’ont pas à être jaloux ; le binding s’y fait pareil, depuis la page de l’appareil.
Deux réserves honnêtes. Un : tous les appareils ne supportent pas le binding — cela dépend de l’implémentation Zigbee du fabricant ; le matériel IKEA est traditionnellement discipliné, d’autres marques ne remontent que partiellement les changements d’état liés. Deux : les boutons à pile dorment profondément — il faut les réveiller pendant la configuration du binding, sinon elle échoue sans un mot. Les deux points figurent dans la documentation liée, les deux se règlent en dix minutes.
Qu’est-ce qui marche encore en direct ?
Z-Wave sait faire la même chose et appelle ça une association. On inscrit la cible dans un des groupes d’association de l’appareil, et celui-ci envoie ensuite son Basic_Set en direct, même quand le contrôleur est éteint ou en panne. Sous Home Assistant, cela se configure depuis la page de l’appareil dans Z-Wave JS, en général à partir du groupe 2. Les commandes sont volontairement sobres : allumer, éteindre, tamiser, point. Pour des réflexes, c’est exactement ce qu’il faut.
S’il y a un Hue Bridge dans la maison, ses propres accessoires forment une couche de plus : un variateur Hue appairé directement au bridge commute ses lampes même quand Home Assistant ne répond pas. À strictement parler, c’est une centrale plus petite plutôt que pas de centrale du tout, mais c’est une deuxième, indépendante — et elle se met à jour bien moins souvent.
Les relais Shelly poussent le principe jusque dans la boîte d’encastrement. L’interrupteur mural physique est câblé sur l’entrée de commutation du relais et commute localement sur l’appareil, Wi-Fi ou pas. Le cas inverse est instructif : le fameux « mode détaché », où l’entrée n’émet plus que des événements et où c’est le serveur qui commute, reconstruit précisément la dépendance dont parle ce billet. Parfois le confort le vaut. Cela doit rester une décision consciente, pas une habitude.
Et Matter ? Le standard prévoit expressément les bindings ; les appareils doivent pouvoir se piloter sans contrôleur au milieu. Home Assistant a ajouté de premières fonctions de binding à son add-on Matter, encore rudimentaires, et le support côté appareils est maigre. À surveiller, pas encore à bâtir dessus. Les gens de KNX peuvent se permettre ici un sourire discret : chez eux, la logique vit dans les appareils depuis des décennies, et le bus ne connaît même pas de serveur central qui pourrait tomber.
Les couches comparées
| Voie | Commute si HA est à terre ? | Réseau nécessaire ? | Puissance logique |
|---|---|---|---|
| Automatisation ESPHome sur la puce | ✅ | ❌ (même pas le Wi-Fi) | moyenne : conditions sur l’appareil |
| Binding Zigbee (appareil/groupe) | ✅ | maillage Zigbee, pas de serveur | faible : on/off/variation/couleur |
| Association Z-Wave | ✅ | radio Z-Wave, pas de contrôleur | faible : commandes basiques |
| Entrée de commutation Shelly (couplée) | ✅ | ❌ | faible : commuter |
| Accessoire Hue sur le bridge | ✅ | Hue Bridge + Zigbee | faible à moyenne |
| Automatisation dans Home Assistant | ❌ | toute la pile | élevée : tout, avec tout le contexte |
La dernière ligne n’est pas la pire. Elle est là pour autre chose. Et c’est exactement le propos : il ne s’agit pas de détrôner Home Assistant, mais de poser chaque morceau de logique sur la couche dont il a réellement besoin. « Allume la lumière » n’a pas besoin d’un interpréteur Python.
Que reste-t-il au cerveau ?
Tout l’intéressant. Les scènes qui coordonnent plusieurs corps de métier. La présence, les horaires, les prix de l’énergie, la météo. Les notifications, les statistiques, le tableau de bord comme fenêtre sur la maison. Externaliser les réflexes ne rétrograde pas Home Assistant : cela le rend plus fiable et plus libre à la fois. Le serveur peut enfin faire ce que lui seul sait faire, et personne ne retient son souffle pendant une mise à jour. C’est la même idée qui rend les installations locales plus résilientes que les dépendances au cloud, appliquée une couche plus bas — à son propre serveur plutôt qu’à celui des autres.
Pour qui installe Home Assistant professionnellement chez des clients, c’est plus que de l’hygiène. Une installation dont les fonctions de base ne sentent ni les mises à jour ni les redémarrages ne génère pas d’appels à 21 heures. On peut mener la maintenance dans une fenêtre propre et limitée dans le temps, mettre à jour le Core, redémarrer des add-ons, et le client ne s’aperçoit de rien. Avec une poignée d’appareils à soi, on vérifie tout ça à la main. Sur vingt installations clients, on veut voir l’état et les mises à jour de toutes au même endroit, sinon le contrôle dévore le temps que l’architecture venait de gagner.
Pour finir, retour dans la douche où ce billet a commencé. La mise à jour du Core tourne, le serveur redémarre, le tableau de bord est gris un instant. Et la lumière ? La lumière s’allume. Parce qu’entre le bouton et la lampe, plus personne n’est assis au milieu avec mieux à faire.