Automatisations Home Assistant : scénarios fiables

C'est une règle écrite dans Home Assistant qui relie un événement à une action, avec des vérifications entre les deux.

Une automatisation n'est pas un programme : c'est une règle « si ceci, alors fais ceci », écrite dans Home Assistant. Le déclencheur ouvre le bal, la condition filtre ce qui passe, l'action exécute. Retirez la condition et la règle se déclenche à contretemps. Ajoutez-la et elle ne part que quand c'est vrai.

Elle vit dans Home Assistant, pas dans l'appareil : couper un capteur ne supprime pas la règle, il la prive seulement de son déclencheur. Alors donnez-lui un ID unique et un nom clair. Sans eux, vous cherchez dans les traces sans savoir quoi corriger. Ça tient le débogage si vous nommez ; ça décroche si vous laissez des automatisation_1 s'empiler.

On part du déclencheur, on ajoute les conditions seulement si elles servent, puis on écrit l'action et on teste à vide.

Commencez par le déclencheur : c'est l'événement qui met l'automatisation en route. Tant que vous ne l'avez pas posé, vous ne savez pas de quoi vous parlez. Ajoutez ensuite une condition seulement si elle sert, car une condition inutile décroche au premier changement d'usage. Écrivez enfin l'action, puis testez à vide.

Vous tenez votre ordre de lecture : déclencheur, condition, action. Ça tient la charge si vous ne sautez pas d'étape, ça décroche si vous empilez des conditions sans raison. Une automatisation se relit dans cet ordre, pas dans l'ordre où vous l'avez tapée.

L'éditeur visuel suffit pour les cas simples, le YAML devient nécessaire dès que la logique se complique.

L'éditeur visuel écrit du YAML à votre place : vous basculez entre les deux vues sur la même automatisation, donc rien ne se perd. Le YAML reste toutefois nécessaire dès que vous touchez aux modèles, aux boucles ou aux conditions imbriquées, car l'interface ne sait plus les représenter.

Mais l'outil n'est pas le sujet. Ce qui décide de la fiabilité, c'est le contenu de vos trois blocs : déclencheur, condition, action. Un scénario écrit à la souris tient la charge si cette logique est propre ; il décroche si elle est bancale, quel que soit l'éditeur.

Les conditions se lisent de haut en bas : toutes doivent passer quand elles sont dans le même bloc, et il suffit d'une pour qu'un bloc OU passe.

Quand vous empilez des conditions, Home Assistant les lit de haut en bas. Une vérification placée avant une autre peut donc limiter la seconde à une partie seulement des cas. Si la première condition bloque déjà l'exécution, celles du dessous ne servent à rien : elles ne seront jamais lues.

Le OU n'est pas une condition isolée, c'est un bloc qui en contient plusieurs. Dès que l'une passe, le bloc passe et l'automatisation continue. Le SI, lui, agit dans l'action : il choisit une branche ou l'autre, jamais les deux. Ça tient la charge tant que vos blocs restent lisibles ; ça décroche dès que l'ordre d'évaluation vous échappe.

Le mode dit ce que Home Assistant fait quand un nouveau déclenchement arrive alors que l'automatisation tourne déjà.

Le mode d'exécution dit ce que Home Assistant fait quand un nouveau déclenchement arrive alors que l'automatisation tourne déjà. Le choix tient à un seul critère : ce qui doit se passer si deux déclenchements se chevauchent. single ignore le second déclenchement tant que le premier n'est pas terminé, restart arrête l'exécution en cours et repart, queued met les suivants en file d'attente, parallel les exécute tous en même temps.

Pour une action qui envoie un message, single suffit souvent : vous ne voulez pas dupliquer la notification. Pour un calcul qui doit refléter le dernier état, restart est le bon réflexe car il repart sur des données fraîches. queued convient quand chaque déclenchement compte et doit être traité dans l'ordre, parallel quand les exécutions sont indépendantes.

Une automatisation dont la condition repose sur un état restauré peut ne jamais se déclencher après un redémarrage, tant que l'état n'a pas été rafraîchi.

Après un redémarrage, Home Assistant ne connaît que ce qu'il a pu restaurer ou recevoir des appareils. Un capteur sur pile qui ne se signale qu'à changement peut donc rester inconnu pendant des heures : une automatisation qui attend un événement précis manquera le coche. Si votre automatisation doit s'appliquer après un redémarrage, faites-la déclencher aussi sur le démarrage, pas seulement sur le capteur.

Certaines intégrations réinjectent le dernier état connu au démarrage, d'autres pas. Comme le sort des états restaurés dépend de l'exposition de chaque intégration, vous ne pouvez pas généraliser. Vérifiez donc ce que voit réellement votre capteur avant de compter dessus, car vous ne pouvez pas généraliser d'une intégration à l'autre.

On vérifie dans l'ordre : le déclencheur a-t-il lieu, la condition passe-t-elle, l'action s'exécute-t-elle vraiment.

Quand une automatisation ne se déclenche pas, la trace est votre meilleur point de départ : elle montre le chemin parcouru et s'arrête exactement là où le scénario a calé. Vous évitez ainsi de chercher au hasard dans le YAML. Si la trace indique que le déclencheur ne s'est jamais produit, vérifiez d'abord l'historique du capteur : la cause est souvent en amont, côté appareil.

Autre cas fréquent. L'action s'exécute bien, mais rien ne change visiblement. Le problème vient alors de l'appareil ou de l'intégration, pas de l'automatisation elle-même, car le scénario a fait son travail. En résumé : la trace vous dit où ça casse, l'historique vous dit si l'événement existe, et l'effet observé vous dit qui est réellement en cause. Ça tient la route tant que vous suivez cet ordre ; ça décroche dès que vous modifiez le YAML avant d'avoir lu la trace.

Une automatisation MQTT se contente d'écouter un sujet publié et de réagir au message reçu, sans passer par un capteur.

L'automatisation MQTT se contente d'écouter. Le déclencheur lit un sujet précis : c'est le sujet, pas l'appareil, qui porte l'information. MQTT est un protocole de publication sur des sujets, donc chaque message part sur un sujet et tout ce qui écoute ce sujet le reçoit. Si votre automatisation écoute un sujet trop large, elle réagit à des messages qui ne la concernent pas.

Comme une charge utile précise peut servir de condition, le message reçu se teste comme n'importe quelle valeur. Voici l'exemple minimal, à adapter à votre sujet et à votre charge utile. Une charge utile précise peut servir de condition, et le message reçu se teste comme n'importe quelle valeur : trigger: - platform: mqtt topic: "votre/sujet" condition: - condition: template value_template: "{{ trigger.payload == 'votre_valeur' }}" action: - service: votre.action

Nommez, datez, documentez : une automatisation lisible est une automatisation que vous saurez réparer dans six mois.

Vous serez celui qui rouvre le fichier dans six mois. Écrivez donc pour ce lecteur-là. Un identifiant unique et stable, une clé que vous ne renommez jamais, résiste aux refontes ; c'est lui qui relie l'automatisation à son historique et à ses erreurs. Le nom, lui, se lit dans l'interface : mettez-le en français clair, il décrit l'intention, pas le mécanisme.

Puisqu'un commentaire dans le code se perd au premier copier-coller, il ne sauve personne. Nommez, datez, documentez : votre automatisation devient alors réparable, parce que vous savez ce qu'elle fait avant d'ouvrir le YAML. Ça tient la charge si la personne qui reprend comprend le nom ; ça décroche si elle doit deviner.

Une automatisation fiable, c'est une règle simple, nommée et testée, dont vous comprenez chaque déclenchement.

La fiabilité ne vient pas de la complexité, mais de la clarté. Une automatisation Home Assistant relie un déclencheur, des conditions et une action : plus cette chaîne reste lisible, plus vous saurez pourquoi elle s'est déclenchée ou non. L'éditeur visuel convient aux cas simples, le YAML prenant le relais quand la logique s'épaissit. Dans tous les cas, testez à vide avant de déployer, et vérifiez chaque maillon en cas de silence : le déclencheur a-t-il eu lieu, la condition est-elle passée, l'action s'est-elle exécutée ?

Les pièges classiques se règlent en amont : un mode d'exécution mal choisi provoque des doubles déclenchements, une condition reposant sur un état non rafraîchi peut ne jamais passer après un redémarrage, et des conditions imbriquées sans logique claire deviennent impossibles à relire. Adoptez donc des réflexes simples : nommer, dater, documenter, et préférer un ID stable à un commentaire perdu dans le code. Une automatisation que vous savez réparer vaut mieux qu'une automatisation brillante que vous n'osez plus toucher.