Mes automatisations Home Assistant qui servent vraiment (et les pièges qui m’ont eu)

Les listes « 50 automatisations Home Assistant géniales » pullulent, et les trois quarts sont des gadgets qu’on désactive au bout d’un mois. Voici l’inverse : les automatisations que ma maison utilise vraiment, les règles qui les rendent fiables, et surtout le récit complet d’un bug qui m’a occupé plusieurs soirées (une lumière de couloir qui refusait de s’éteindre une fois sur quatre), parce qu’on apprend plus d’une panne disséquée que de cinquante recettes copiées.

---

Le vrai critère d’une bonne automatisation

Après quelques années de domotique, mon critère tient en une phrase : une bonne automatisation, c’est celle qu’on remarque le jour où elle casse. Pas celle qui impressionne les invités. Celle dont la famille dit « la lumière du couloir déconne » sur le ton qu’on emploie pour une panne d’eau chaude, parce qu’elle est devenue de l’infrastructure. Si personne ne râle quand votre automatisation s’arrête, supprimez-la : c’était un jouet.

Trois règles m’ont épargné beaucoup de soirées de debug (pas toutes, on va le voir) :

• Simple bat malin. L’automatisation à douze conditions qui anticipe vos envies finit toujours par vous surprendre un dimanche. Celle qui fait une chose évidente marche dix ans.
• Une automatisation = un boulot. Allumer, c’est un boulot. Éteindre après un délai, c’en est un autre. Les mélanger dans un seul bloc est exactement le piège dans lequel je suis tombé (patience, l’autopsie arrive).
• Tout doit être réglable sans toucher au code. Les durées, les seuils de luminosité : dans des helpers modifiables depuis l’interface. Le YAML décrit la logique, jamais les goûts du jour.

Celles qui tournent vraiment chez moi

Le couloir qui s’allume tout seul (la vedette du foyer)

Un capteur de présence Aqara au plafond, un groupe d’ampoules, et une règle : présence détectée, lumière allumée (tamisée la nuit, franche le jour) ; présence perdue, extinction au bout de 60 secondes. C’est l’automatisation la plus banale du monde et la plus rentable de la maison : les mains pleines de linge, personne ne cherche l’interrupteur. Le capteur de présence à ondes millimétriques (par opposition au détecteur de mouvement classique) change tout dans un couloir : il voit quelqu’un d’immobile, donc la lumière ne s’éteint pas sur la personne qui lit debout devant la bibliothèque.

Les toilettes, ou l’automatisation qui porte son histoire dans son nom

Dans ma configuration, l’automatisation des toilettes s’appelle officiellement « Éclairage Intelligent (Anti-Extinction) ». Le nom est un aveu gravé dans le marbre : sa première version a éteint la lumière sur un occupant immobile, l’occupant a protesté (à juste titre, et avec l’autorité de la personne assise dans le noir), et la version suivante a été baptisée en mémoire de l’incident. Aujourd’hui, la pièce a droit à cinq réglages dédiés, modifiables sans toucher au code : luminosité de jour (100 %), de nuit (20 %, personne ne veut un phare à 3 heures du matin), et trois délais selon le contexte. Cinq curseurs pour des toilettes. C’est objectivement ridicule, et c’est exactement le niveau de soin que réclame la seule pièce où l’échec de l’automatisation a un public captif.

L’extinction sur absence, pièce par pièce

Le même principe étendu au salon : quand la présence retombe, un minuteur part, et tout s’éteint proprement. La version salon a un seul déclencheur et une seule mission, et vous verrez plus bas que ce détail d’architecture, qui m’avait semblé anecdotique, est exactement la raison pour laquelle elle n’est jamais tombée en panne quand sa cousine du couloir, plus ambitieuse, se vautrait une fois sur quatre.

L’interrupteur qui garde le dernier mot

Règle de paix des ménages : chaque automatisation d’éclairage doit pouvoir être contredite par un humain, au mur, sans sortir le téléphone. Chez moi, les boutons physiques passent devant l’automatisation (un appui qui éteint annule le minuteur en cours, un appui qui allume arme une temporisation dédiée). Le jour où votre domotique impose ses choix à quelqu’un qui voulait juste de la lumière, vous perdez votre licence d’exploitation domestique. Elle ne se renégocie pas facilement.

Les petites sentinelles

Le reste de mon armada est moins spectaculaire et tout aussi utile : une notification si une porte reste ouverte au-delà d’un délai raisonnable, des éclairages qui suivent les plages du soleil (on va beaucoup reparler de lui), et surtout la sentinelle des piles. Une vingtaine de capteurs à batterie vivent dans cette maison, et un capteur à pile morte est une automatisation morte en silence : personne ne s’aperçoit que le détecteur d’ouverture s’est tu, jusqu’au courant d’air. Mon automatisation d’alerte batterie me dénonce donc chaque traînard (au moment où j’écris, un module d’interrupteur affiche 12 % et me regarde droit dans les yeux depuis trois semaines, la sentinelle fonctionne, le sentinellé procrastine). Rien de tout ça ne fait une démo sexy. Tout ça fait une maison qui marche.

Autopsie d’un bug : la lumière qui ne s’éteignait plus

Venons-en au plat de résistance. Ce qui suit est le récit fidèle d’un bug réel de mon installation, diagnostiqué à la sonde et corrigé un premier août. Je le raconte en détail parce qu’il combine trois pièges de Home Assistant que tout le monde finit par rencontrer, et que je n’avais trouvé nulle part racontés ensemble.

Le symptôme : « j’ai l’impression que »

La lumière du couloir, celle de l’automatisation vedette, restait parfois allumée alors que le couloir était vide depuis longtemps. Parfois. Pas toujours, pas à heure fixe, pas après un événement identifiable. Le bug intermittent est le pire des adversaires domestiques : on doute du capteur, on doute de soi, la famille commence des phrases par « j’ai l’impression que ». L’historique confirmait pourtant : sur 48 heures, quatre épisodes où la lumière était restée allumée de 13 à 30 minutes après le départ du dernier passant, pour un délai réglé à 60 secondes. Et un détail redoutable : aucun de ces épisodes ne s’était terminé par une extinction automatique. À chaque fois, c’est un nouveau passage dans le couloir qui avait remis le système d’aplomb. La signature d’un minuteur qui ne meurt pas en retard, mais qui meurt tout court.

Le coupable : le soleil, à la milliseconde près

Mon automatisation du couloir gérait tout à la fois (allumage, luminosité selon l’heure, boutons muraux, extinction), en mode: restart, avec six déclencheurs. Dont celui-ci, qui adaptait l’éclairage aux plages de la journée :

- entity_id: sun.sun
  id: plage_change
  trigger: state      # aucun "to:", aucun "attribute:"

Le piège n° 1 est là, et il est générique : un déclencheur d’état sans to:, from: ni attribute: se déclenche sur tout changement de l’entité, y compris un simple changement d’attribut. Or l’entité sun.sun recalcule en permanence l’élévation et l’azimut du soleil : une émission toutes les quatre minutes en journée. Mon déclencheur « lever ou coucher du soleil » partait en réalité 353 fois par jour.

Ajoutez le piège n° 2 : en mode: restart, chaque déclenchement tue l’exécution en cours pour en démarrer une nouvelle. Déroulez le film au ralenti. La présence tombe, la branche extinction démarre son delay de 60 secondes. Pendant cette minute, environ une fois sur quatre, le soleil bouge. Le redémarrage tue le délai en cours, et l’extinction qui devait suivre. La nouvelle exécution regarde sa condition (« présence détectée »), la trouve fausse, et se termine sans rien faire. Le minuteur n’est pas retardé : il est perdu, définitivement. La lumière restera allumée jusqu’au prochain humain. C’était une course entre le soleil et mon minuteur, et le minuteur perdait une manche sur quatre.

La preuve (et le piège n° 3, le plus vicieux)

Pour passer de l’hypothèse à la certitude, une sonde en direct sur l’API, couloir vide, présence à zéro : à chaque mise à jour de sun.sun, le last_triggered de l’automatisation bougeait à la milliseconde près, toutes les quatre minutes. Flagrant délit.

Mais voici le piège n° 3, celui qui m’a coûté le plus de temps : l’historique de Home Assistant ne montre pas ces déclenchements-là. L’enregistreur ignore par défaut les changements non significatifs, et l’intégration soleil exclut volontairement l’élévation et l’azimut de la base (sinon elle enflerait pour rien). Autrement dit, l’outil avec lequel tout le monde débogue affirmait que sun.sun était calme, pendant que le bus d’événements hurlait toutes les quatre minutes. Si votre automatisation se déclenche « toute seule » et que l’historique ne montre rien : regardez last_triggered dans les attributs, ou sondez le bus en direct. L’historique est une sélection, pas la vérité.

Le correctif : séparer les pouvoirs

Deux gestes. D’abord, borner le déclencheur fautif à ses deux vrais états, ce qui l’a fait passer de 353 déclenchements par jour à 2 :

- entity_id: sun.sun
  to:
    - "above_horizon"
    - "below_horizon"
  id: plage_change
  trigger: state

Ensuite, et surtout, scinder l’automatisation en deux : une pour l’ambiance (allumage, luminosité, boutons), qui peut redémarrer autant qu’elle veut puisqu’elle ne porte aucun délai, et une pour l’extinction, qui porte les minuteurs et n’accepte que les déclencheurs ayant une raison légitime de les reprogrammer. C’est la leçon que je fais encadrer :

Une automatisation qui porte un delay ne doit accepter que les déclencheurs qui ont une raison légitime de reprogrammer ce délai. Tout le reste vit ailleurs.

Depuis le correctif, la sonde est formelle : le soleil se met à jour, l’automatisation ne bronche plus, et le couloir s’éteint. Bilan annexe de l’enquête, comme souvent : un réglage de temporisation manuelle déclaré depuis des mois et branché nulle part (l’appui sur le bouton du mur allumait pour l’éternité), et deux automatisations fantômes en unavailable, reliquats d’une vieille migration, purgées du registre. On ouvre le capot pour une fuite, on ressort avec trois réparations.

Ce que je n’automatise plus (l’aveu qui vaut toutes les recettes)

La partie que les listes d’automatisations géniales ne montrent jamais : le cimetière. Chez moi, onze automatisations de volets roulants (ouverture au soleil, fermeture au crépuscule, protection canicule, protection gel, simulation de présence pour les vacances, réveil progressif) dorment actuellement désactivées, après des dizaines d’heures de mise au point dont je ne suis pas peu fier. Pourquoi ? Parce que la réalité d’un foyer est plus têtue qu’un YAML : quelqu’un fait la sieste à l’heure de l’ouverture solaire, un volet décide de vivre sa vie, et la valeur de l’automatisation ne compense plus ses exceptions. Le chauffage raconte l’inverse : là, je n’automatise presque rien dans Home Assistant parce que les vannes thermostatiques font le travail localement, toutes seules, y compris couper le radiateur quand une fenêtre s’ouvre. La meilleure automatisation est parfois celle qu’on n’écrit pas.

Ma grille de tri, à froid : une automatisation gagne sa place si elle tourne un mois sans qu’on parle d’elle. Elle la perd si quelqu’un doit la contourner deux fois. Entre les deux, on règle, on simplifie, ou on débranche sans état d’âme. Le YAML supprimé ne vexe personne.

La généralisation : où ce piège vous attend

Le déclencheur trop bavard ne se cache pas que dans le soleil. Toute entité à attributs vivants fait le même coup : un device_tracker qui met à jour ses coordonnées GPS, une entité météo qui rafraîchit sa température, un lecteur multimédia qui égrène sa position de lecture. Un déclencheur d’état nu posé dessus, et vous avez des dizaines à des centaines de déclenchements quotidiens invisibles dans l’historique. Combinez avec mode: restart et un delay, et vous obtenez mon couloir : un système qui marche « presque toujours », l’expression la plus chère de la domotique.

La check-list qui m’aurait évité tout ça : chaque déclencheur d’état a-t-il un to:, un from: ou un attribute: explicite ? Chaque automatisation à delay est-elle en mode: restart pour la bonne raison (reprogrammer le délai) et pour elle seule ? Et chaque helper déclaré est-il branché quelque part, ou dort-il dans la config comme le mien depuis des mois ?

FAQ : le service après-panne

Pourquoi mon automatisation ne se déclenche-t-elle pas ?

Dans l’ordre des causes les plus fréquentes : une condition qui n’est pas remplie au moment du déclenchement (la condition se teste à cet instant-là, pas avant ni après), un déclencheur qui attend un état exact et reçoit autre chose (« on » n’est pas « On », et l’identifiant d’entité n’est pas son joli nom d’affichage), et l’automatisation désactivée sans que personne s’en souvienne. L’outil qui tranche tout : ouvrir l’automatisation, onglet des traces, et relire les dernières exécutions pas à pas. Chaque trace montre le déclencheur qui a parlé, chaque condition évaluée avec son verdict, et l’endroit exact où le chemin s’est arrêté. C’est l’équivalent domotique de la boîte noire, et neuf mystères sur dix n’y survivent pas cinq minutes.

Elle se déclenche trop, au contraire. Comment trouver le déclencheur fautif ?

Donnez un id à chaque déclencheur (une ligne de YAML), et les traces vous diront lequel a parlé. Si last_triggered bouge alors que l’historique semble calme, pensez à mon couloir : les changements d’attributs n’apparaissent pas dans l’historique, sondez le bus d’événements en direct.

Mode single, restart, queued, parallel : lequel choisir ?

single (le défaut) ignore un nouveau déclenchement tant que le premier tourne : bien pour les actions instantanées. restart repart de zéro : parfait pour les minuteurs qu’un aller-retour doit reprogrammer, dangereux dès qu’un déclencheur étranger au minuteur traîne dans la liste (relisez l’autopsie ci-dessus). queued et parallel servent des cas particuliers (files d’actions, exécutions simultanées) : si vous hésitez, ce n’est probablement pas eux.

Éditeur visuel ou YAML ?

Les deux, sans dogme. L’éditeur visuel est parfait pour démarrer et pour les traces de debug ; le YAML devient précieux quand on veut versionner sa configuration, la relire, la commenter (ma règle encadrée vit en commentaire au-dessus de l’automatisation fautive) et comprendre finement ce qu’on a écrit. Le pas à pas de l’installation et la philosophie de la config versionnée sont dans le deuxième article de la série.

Repères

• Une bonne automatisation est celle qu’on remarque quand elle casse.
• Un déclencheur d’état sans to:, from: ni attribute: capte aussi les changements d’attributs : sur sun.sun, ça fait 353 déclenchements par jour au lieu de 2.
• En mode: restart, tout déclencheur étranger au minuteur tue silencieusement le delay en cours.
• L’historique ne montre pas tout : last_triggered et le bus d’événements, si.
• Séparez l’ambiance de l’extinction : une automatisation, un boulot.
• Durées et seuils dans des helpers, jamais en dur dans le YAML.

Cette série commence par les protocoles enfin compris et continue avec le pas à pas Home Assistant sur Raspberry Pi. Bonnes pannes.