Automatisation #2 : libérer le plein potentiel !

Bienvenue dans ce deuxième article de la série automatisations. Il fait suite à ce précédent article, qu'il est conseillé de lire au préalable :

Automatisation #1 : débuter en douceur !

Vous ne savez pas par où commencer les automatisations sous Home Assistant ? Découvrons ensemble les possibilités offertes par les déclencheurs, conditions et actions afin de réaliser les premières automatisations.

Home Assistant Communauté FrancophoneBBE

Vous voulez passer de la première ampoule qui s'allume seule aux scénarios les plus sophistiqués, alors suivez le guide...

Pour commencer

Cet article va plonger plus en profondeur dans les possibilités offertes par les déclencheurs, les conditions et les actions. Il vous permettra, j'espère, d'étoffer vos connaissances et de réaliser des automatisations de plus en plus précises, qui répondent à vos besoins les plus complexes.

Rappels des bases

Si vous n'avez pas lu le premier article : Automatisation #1 : débuter en douceur ! c'est le moment de le faire!

Pour mémoire, toute automatisation repose sur trois éléments fondamentaux: déclencheurs, conditions et actions, les comprendre est indispensable pour maîtriser Home Assistant.

Lorsqu'un événement se produit (le déclencheur), on vérifie si certaines conditions sont remplies (les conditions), et si oui, des actions spécifiques sont exécutées (les actions).

Ceci est formulé de la façon suivante dans l'interface graphique :

• Quand le déclencheur se produit
• Et si les conditions sont satisfaites (facultatif)
• Alors faire les actions

Nouveauté les logiques de ciblage

De nouvelles mécaniques sont en cours de développement dans Home Assistant en ce qui concerne les déclencheurs, les conditions et les actions. Elles vous permettront de réaliser vos automatisations de façon différente, plus naturelle. Elles seront détaillées plus loin dans l'article. Pour les activer (car pour l'instant, elles sont expérimentales) il faut aller dans le "Labs" Home Assistant :

Allez dans Système :

Puis cliquez sur Labs :

Et activez les déclencheurs et conditions orientés usage :

Une fois fait, vous remarquerez qu'un onglet "cible" est apparu dans les interfaces d'ajout de déclencheur et de conditions, nous en parlerons plus loin dans chaque chapitre.

Les Déclencheurs : Détecter l'événement avec précision

Le déclencheur est un des points critiques de votre automatisation. Bien le choisir vous permettra de démarrer vos automatisations au moment opportun. Nous allons détailler les déclencheurs afin de permettre à vos automatisations de s'activer de manière intelligente, au-delà du simple test d'état que nous avons utilisé dans le premier article.

Avant même d'activer le mode Labs, nous disposons déjà de nombreux déclencheurs :

Le mode "cible" que nous verrons par la suite permet de simplifier ou de généraliser des déclencheurs. Mais les déclencheurs "de base" restent les mêmes et connaître leur fonctionnement est essentiel.

Le déclencheur Entité (entity)

Nous l'avons vu dans notre article précédent, on peut déclencher une automatisation sur les états d'une entité.

Soit sur l'Etat (state) :

Soit sur l'Etat numérique (numerical-state) :

C'est le type de déclencheur le plus courant et l'un des plus puissants. Nous allons donc le détailler un peu, car il est déjà capable de faire beaucoup de choses !

On peut déclencher sur l'état ou sur une valeur numérique (seuil). Mais on peut aussi ajouter une notion temporelle, ou même tester plusieurs entités ou des attributs.

On va ainsi pouvoir déclencher une automatisation :

• Lorsqu'une entité prend un état défini, champ : A (comme nous l'avons vu dans le premier article) : Quand un détecteur s'active, Quand le soleil devient "sous l'horizon", quand un interrupteur devient "activé", quand une lampe s'allume, etc...
• Lorsqu'une entité devient supérieure à, champ : Au dessus de ou inférieure à, champ : En-dessous de ou les deux par rapport à un seuil défini (en utilisant Etat numérique - nombre fixe) : quand la température devient supérieure à 15°C, quand la luminosité devient inférieure à 55, quand la température sort de la plage 20-23°C, quand la batterie devient inférieure à 15%, quand la puissance de la prise connectée devient supérieure à 100W, etc...
• Lorsqu'une entité devient supérieure champ: Au dessus de ou inférieure champ: En-dessous de ou les deux par rapport à une autre entité (en utilisant Etat numérique - valeur numérique d'une autre entité) : quand la température intérieure devient supérieure à la température extérieure, quand la luminosité d'un capteur devient inférieure à une cible fixée dans un input-number, quand la puissance de la production solaire devient supérieure à la consommation de la maison, etc...
• En ajoutant une notion de temps, champ: Pendant on ne déclenchera que si un état particulier persiste pendant une certaine période. Très utile pour éviter les faux positifs ou encore créer un délai : quand une porte est ouverte depuis 10min, quand une lumière est allumée depuis 5min, quand la température est supérieure à -15°C depuis 5 min, quand l'état est "en charge" depuis 5h, etc... Dans ce cas-là le déclencheur ne deviendra vrai que lorsque la durée sera écoulée.
• On peut aussi spécifier un état d'origine champ: De, avec ou sans état cible : quand le chauffage n'est plus "auto", quand le tarif tempo n'est plus "rouge", quand le tarif passe de "HC" à "HP", etc...
• On peut également faire tout ce qu'on vient de voir précédemment avec un attribut d'une entité champ: Attributet non plus l'état de l'entité elle-même : quand la température cible du chauffage devient supérieure à 24°C, quand la luminosité de l'ampoule devient inférieure à 50%, quand la vitesse de ventilation n'est plus "auto", etc..
• On peut si l'on veut sélectionner plusieurs entités. On aura alors un déclenchement lorsque l'une des entités est dans l'état sélectionné : quand l'un des détecteurs de mouvement sélectionnés s'active, quand l'une des températures sélectionnées devient inférieure à 15°C, etc...
• On peut même spécifier plusieurs états champ : A, ou même n'importe quel état champ A cliquer sur N'importe quel état, dans ce cas là dès que l'entité changera d'état, le déclencheur lancera l'automatisation : quand le chauffage change d'état, quand le booléen "mode automatique" change d'état, quand le tarif tempo devient "rouge" ou "blanc", quand l'ampoule change d'état, etc...

Si vous connaissez bien vos entités, ce déclencheur sera redoutable, et pour en savoir plus sur les états de vos entités faites un tour dans les outils de développement, onglet Etat :

Le déclencheur Appareil (device)

Le déclencheur appareil semble pratique pour débuter, car il est très simple et naturel à utiliser :

On choisit un appareil, et il nous propose des déclencheurs associés, une interface peut être un peu plus simple que le déclencheur entités.

Mais attention, car il ne propose en fait rien de plus que le déclencheur entité que l'on vient de voir, donc si vous connaissez bien vos entités, il ne vous apporte rien de plus.

Mais surtout, il possède un défaut majeur : il devient illisible en YAML. Donc il risque de vous empêcher de progresser : ci-dessous deux déclencheurs, une entité et un appareil, détectant le passage en mode chauffage de ma PAC (ils réalisent donc exactement la même chose) :

Lorsqu'on passe en mode YAML :

triggers:

# declencheur Appareil
  - trigger: device
    device_id: 5b89093e82e42fe555148e26a107faba
    entity_id: fe8907573739d862acee9459abe1c731
    domain: climate
    type: hvac_mode_changed
    to: heat
    
# declencheur Entité
  - trigger: state
    entity_id: climate.pac
    to: heat

Les deux déclencheurs font exactement la même chose, mais le déclencheur "Appareil" est beaucoup moins facile à lire en YAML que le déclencheur "Entité" qui affiche en clair l' entity_id de ma PAC au lieu d'un code illisible.

Déclencheurs Heure et lieu

• Le Déclencheur Calendrier (calendar) : Si vous avez défini des événements dans un calendrier, il se déclenche au début ou à la fin d'un évènement du calendrier, éventuellement avec un décalage (un temps avant ou après le moment défini). À utiliser pour les rappels de sortie des poubelles, des notifications d'anniversaire.
• Le Déclencheur Heure (time) : Tout simple, se déclenche à l'heure définie. On peut également spécifier des jours de la semaine, ou même un jour et une heure particuliers. À utiliser pour une automatisation à heure fixe, par exemple ouvrir les volets à 7h en semaine, et faire un deuxième déclencheur pour les ouvrir à 9h samedi et dimanche, un réveil, un rappel.
• Le Déclencheur Modèle de temps (time_pattern) : Un peu subtil, va se déclencher lorsque l'heure aura un format défini, par exemple si on met "10" dans la case des minutes, va se déclencher toutes les heures à "et dix" (à 0h10, 1h10, 2h10, etc...). si on met "/10", va se déclencher chaque fois que le nombre des minutes est "divisible par 10", donc en pratique toutes les 10 minutes (à 0h10, 0h20, 0h30, etc...). À utiliser pour une automatisation répétitive, et avec parcimonie car on peut vite surcharger le système.
• Le Déclencheur Soleil (sun) : se déclenche au lever ou au coucher du soleil, éventuellement avec un décalage (À noter que l'on peut faire la même chose avec un déclencheur entité et l'entité sun.sun) : à utiliser pour des automatismes de volet, de lumière.
• Le Déclencheur de Zone (zone) : Votre maison sait où vous êtes ! Il se déclenche lorsqu'une entité de personne ou un device-tracker (votre téléphone, par exemple) entre ou sort d'une zone géographique définie dans Home Assistant. Parfait pour l'activation ou la désactivation du mode "Absence" ou pour anticiper l'ouverture du portail et l'allumage des lumières en arrivant près de la maison, l'armement du chauffage quand vous quittez votre bureau, ou toute autre possibilité à inventer.

Les autres déclencheurs

• Le déclencheur évènement manuel (event) : Les évènements sont un des blocs de base du fonctionnement de Home assistant. Certaines intégrations émettent des évènements qui peuvent être intéressants comme déclencheur d'automatisation. Pour les utiliser, il faudra savoir quelles intégrations déclenchent des évènements afin de les spécifier (en YAML) dans les données de l'évènement. Par exemple, la fin d'un timer, un appui bouton sur une télécommande, l'ajout d'une nouvelle note sur Pronote.

Pour en savoir plus sur vos évènements, n'hésitez pas à utiliser les outils de développement, onglet Événements :

• Le déclencheur géolocalisation (geo_location) : Utilisable pour certaines plateformes d'alerte géolocalisées (GDACS pas exemple), à ne pas confondre avec le trigger de Zone. Par exemple, alerte incendie de forêt signalée dans GDACS dans la zone spécifiée.
• Le déclencheur Home assistant (homeassistant) : utilise les évènements liés au démarrage ou à l'arrêt de home assistant, pratique pour lancer une action au démarrage, ou juste avant l'extinction (l'action devra être rapide pour s'effectuer avant l'arrêt de HA).

• Le Déclencheur Modèle (template) : C'est le couteau suisse des déclencheurs. Il vous permet de lancer l'automatisation en utilisant un modèle au format JINJA2 qui peut contenir une logique complexe qui combine plusieurs états ou attributs d'entités, le tout avec si besoin une confirmation en temps. Ceci permet par exemple de faire un trigger sur une condition ET.
  
  Par exemple : Déclencher une action quand la condition (l'ampoule est allumée ET le capteur de mouvement ne détecte personne) est vraie depuis 15 minutes.

Et pour tester vos modèles plus facilement, faites un tour dans les outils de développement, onglet Modèle :

• Le déclencheur de notification persistante (persistent_notification) : permet de déclencher une automatisation lorsqu'une notification est ajoutée, supprimée, mise à jour.

Il s'agit de la présence des notifications visibles en bas de la barre latérale, juste au-dessus de votre utilisateur :

• Le déclencheur phrase (conversation) : Si vous utilisez Assist pour piloter Home Assistant, vous pouvez lui définir des phrases particulières afin de lancer des actions spécifiques. Par exemple, éteindre toutes les lumières si vous dites la phrase "C'est pas Versailles ici".

• Le déclencheur Tag (tag) : Si vous avez programmé des tags NFC ou des QR codes (voir dans paramètres / tags), ces tags peuvent être utilisés comme déclencheurs. Lorsqu'un tag particulier est scanné par un téléphone disposant de l'appli companion ou par un lecteur de tag associé à HA, on pourra alors lancer une automatisation. Par exemple, un tag NFC dans la voiture, le scanner lance une automatisation qui allume les lumières extérieures.
• Le déclencheur webhook (webhook) : vous permet de lancer une automatisation lorsque quelqu'un se connecte sur l'adresse http://your-home-assistant:8123/api/webhook/allumage-ampoule-password (Attention ! N'utilisez pas de web-hooks trop simples, ni pour des fonctions critiques, car il suffit d'avoir le raccourci pour pouvoir lancer l'automatisation) suivant la méthode utilisée (à définir en YAML) on peut travailler soit en GET (dès qu'on accède à l'url, soit en POST (et là, on peut également envoyer des variables) soit les deux. La déclaration du webhook se fait à la création du déclencheur, choisissez donc bien son ID (ici, il faudrait changer password par un "vrai" code).

Nouveauté depuis 2025.12 : Les Déclencheurs par cible

Les dernières versions simplifient encore l'automatisation en adoptant une approche ciblée, ce qui rend l'expérience plus intuitive et accessible. Attention c'est encore en développement et cela risque donc d'évoluer (les traductions ne sont pas encore toutes disponibles en français, le nombre de domaines disponibles est en augmentation d'une version à l'autre).

Au lieu de dépendre d'options techniques basées sur l'état, comme on l'a vu précédemment, on peut désormais choisir des options fournies directement par les domaines comme "lumière" ou "thermostat" (ex : "Quand une lumière s'allume", "Quand le thermostat se met en chauffe", "Quand le thermostat s'éteint"), ce qui peut s'avérer plus intuitif.

Mais surtout, cette nouvelle approche prend en charge le ciblage, une fois la transition à observer définie, il faudra définir les entités ciblées, et on va voir que cela ouvre des possibilités nouvelles.

Si on a activé ce mode dans Labs comme montré dans l'introduction, l'interface des déclencheurs est devenue :

Il y a donc désormais deux onglets : Cibles et Déclencheurs, ce qui signifie que l'on va pouvoir créer les déclencheurs de deux façons, soit par cible, soit par type de déclencheurs.

Commençons par l'onglet déclencheurs :

On observe l'apparition de nouveaux déclencheurs, comme par exemple "Lumière" ou "Thermostat" qui vont nous permettre de définir des déclencheurs liés aux états des entités de ces domaines. Par exemple pour Lumière (en 2025.12 l'interface n'est pas encore traduite en français) :

• "Light turned On" : lorsqu'une ou plusieurs lumières s'allument
• "Light turned Off" : lorsqu'une ou plusieurs lumières s'éteignent

On peut ainsi définir un trigger lorsqu'une des lumières qui seront ciblées s'allume, ou s'éteint. Par exemple pour l'extinction :

On voit qu'il y a trois options :

• first : lorsque la première lumière ciblée s'éteint (Quand la première lumière ciblée s'éteint, l'automatisation démarre)
• last : lorsque la dernière lumière ciblée s'éteint (Quand toutes les lumières ciblées sont éteintes, l'automatisation démarre)
• any : lorsque n'importe laquelle des lumières ciblées s'éteint (Quand et à chaque fois qu'une lumière du groupe cible s'éteint, l'automatisation démarre)

Il nous reste donc à définir des cibles pour finir notre déclencheur, en cliquant sur "+ ajouter une cible":

On va dans cette interface pouvoir spécifier autant de lumières que nécessaire pour notre déclencheur, en les sélectionnant par entité, par appareil, mais aussi (et c'est nouveau), par pièces ou par étiquettes, comme on va le voir tout de suite avec l'autre mode de création de déclencheur.

L'autre manière de définir ce trigger par zone est de le faire par cible :

• par exemple par Zone : étage ou pièce (floorou area). Si dans l'onglet Cibles, vous sélectionnez une zone, l'interface vous donnera tous les déclencheurs disponibles pour cette zone (issus des différents équipements présents dans la zone) :

En sélectionnant le déclencheur "Lumière" dans la pièce salon, vous retrouvez l'interface précédente, avec la cible déjà sélectionnée sur "salon" (mais rien ne vous empêche de modifier ou ajouter des cibles ensuite). Au final, c'est le même type de déclencheur, que l'on peut sélectionner de deux façons dans l'interface : via le type ou via les cibles.

Vous pouvez ainsi déclencher une automatisation lorsque n'importe quelle lumière de votre salon s'éteint, sans devoir créer un groupe ou lister les entités une par une.

• On peut également cibler par Étiquettes (labels) : Le système gère également les étiquettes pour cibler des groupes d'appareils (ex : vérifier l'état de toutes les lumières avec l'étiquette "Éclairage d'Ambiance" ou "Éclairage de Noël"), et de la même façon que pour le ciblage par zone, ajouter ou retirer cette étiquette sur une lumière la prendra en compte dans le déclencheur sans avoir besoin de mettre à jour l'automatisation. Par exemple chez moi l'étiquette "Alexa smart home" regroupe toutes les entités pilotables par Alexa.

Ces déclencheurs par cibles sont pour l'instant disponibles sur les quelques domaines suivants :

• les lumières
• les thermostats
• les aspirateurs
• les ventilateurs
• les capteurs de présence
• les lecteurs multimédia
• les capteurs d'alarme

Ils vont continuer à évoluer avec l'apparition de nouveaux déclencheurs et de nouveaux domaines, la traduction en Français, et peut être des évolutions d'interface. Mais cette nouvelle façon de définir les déclencheurs est très prometteuse.

Bilan

Nous avons donc un panel extrêmement varié de déclencheurs disponibles pour lancer nos automatisations. Dans certains cas, il sera utile d'utiliser plusieurs déclencheurs pour lancer une même automatisation, afin de bien capturer l'ensemble des situations qui sont susceptibles de nécessiter le démarrage de celle-ci.

Pour mémoire, n'importe lequel des déclencheurs suffit à lancer l'automatisation.

Mais alors, si on utilise de nombreux déclencheurs, on risque aussi de lancer l'automatisation à des moments non désirés… Il est donc temps de passer à l'étape suivante : les conditions.

Les Conditions : filtrer avec logique et finesse

Bien que facultatives, les conditions sont les surveillantes de l'automatisation. Elles vous permettent de vérifier la situation actuelle pour éviter de lancer des actions au mauvais moment ou dans un contexte inapproprié. Bien maitriser vos conditions et bien les accorder aux déclencheurs vous permettra d'avoir la bonne automatisation au bon moment.

Par exemple dans de nombreux cas, vous serez sans doute amenés à avoir beaucoup de déclenchements afin de ne pas rater des évènements spécifiques, puis à faire le tri avec les conditions pour ne réaliser les actions que dans un environnement bien précis.

Avant même d'activer le mode ciblage dans Labs, nous disposons de nombreuses conditions, mais aussi (contrairement aux déclencheurs) d'un onglet "Blocs" :

Commençons donc par ces fameux blocs.

Les blocs et la logique

L'onglet "Blocs" nous permet de créer des opérateurs logiques pour combiner entre elles les conditions. Pour rappel, si on place directement plusieurs conditions, il faudra qu'elles soient toutes vraies au moment du déclencheur pour que l'automatisation se poursuive. Les blocs vont nous permettre de changer cette manière de fonctionner.

• L'Opérateur Logique PAS (not) : Ce bloc vous permet d'ajouter une ou plusieurs conditions à l'intérieur. Le bloc autorisera l'exécution de l'automatisation si l'ensemble des conditions qu'il contient ne sont pas satisfaites. Exemple, tester si quelqu'un n'est pas à un endroit, tester si une entité n'est pas dans un état défini, tester si une entité n'est pas "indisponible", tester si aucune présence n'est détectée par plusieurs détecteurs.

• L'Opérateur Logique OU (or) : Cette option vous permet d'autoriser l'exécution de l'automatisation si la Condition A OU la Condition B est vraie. C'est parfait pour les scénarios qui peuvent être validés par plusieurs situations différentes. Exemple, effectuer une annonce sur une enceinte connectée SEULEMENT SI une présence est détectée par le capteur du salon OU qu'une présence est détectée par le capteur de la salle à manger.

• L'Opérateur Logique ET (and) : On l'a vu, c'est la règle de base par défaut. Lorsque vous ajoutez plusieurs conditions, elles doivent toutes être vraies pour que l'automatisation puisse continuer. Mais si besoin, vous pouvez aussi réaliser ce ET dans un bloc logique, en particulier si vous devez enchainer les blocs ET, OU et PAS. Exemple, allumer la lumière du couloir à 19h SEULEMENT SI il fait nuit ET qu'une personne est présente.

• Bien sûr, vous pouvez enchainer ces blocs les uns dans les autres pour créer des logiques complexes imbriquées à base de ET, OU et PAS...

On peut donc combiner les conditions de façon logique, pour faire des tests complexes, mais quelles conditions peut-on tester ?

Comme pour les déclencheurs, nous avons un panel varié. Vous reconnaitrez des interfaces proches des déclencheurs, sauf que dans les déclencheurs, nous cherchions à capturer un moment alors qu'ici, nous chercherons à vérifier que nous sommes dans la bonne configurations. Les notions sont tout de même assez proches, donc nous devrions réussir à aller assez vite :

La condition Entité (entity)

Nous l'avons vu dans notre article précédent, on peut conditionner une automatisation sur les états d'une entité.

Soit sur l'Etat (state) :

Soit sur l'Etat numérique (numerical_state) :

C'est le type de condition le plus courant et l'un des plus puissants. Nous allons donc le détailler un peu plus.

On a vu que comme le déclencheur, on peut tester l'état ou une valeur numérique (seuil) ou tester des attributs.

On va ainsi pouvoir conditionner une automatisation :

• Si une entité prend un état défini champ: Etat (comme on l'a déjà fait dans le premier article) : Si une présence est détectée, Si le soleil est "sous l'horizon", Si un interrupteur est "activé", si une lampe est allumée, etc...
• Si une entité est supérieure champ: Au dessus de ou inférieure champ: En-dessous de ou les deux par rapport à un seuil défini (en utilisant Etat numérique - Nombre fixe) : Si la température est inférieure à 16°C, Si la luminosité est inférieure à 55, Si la température est hors de la plage 20-23°C, Si la batterie est inférieure à 15%, Si la puissance de la prise connectée est supérieure à 100W, etc...
• Si une entité est supérieure champ: Au dessus de ou inférieure champ: En-dessous de ou les deux par rapport à une autre entité (en utilisant Etat numérique - valeur numérique d'une autre entité) : Si la température intérieure est supérieure à la température extérieure, si la luminosité d'un capteur est inférieure à une cible fixée dans un input-number, si la puissance de la production solaire est supérieure à la consommation de la maison, etc...
• En ajoutant une notion de temps, champ: Pendant on n'autorisera l'automatisation à se poursuivre que si un état particulier a persisté pendant une certaine période. si une porte est ouverte depuis 10min, si une lumière est allumée depuis 5min, si l'état est "en charge" depuis 5h, etc... Attention, la condition est testée au moment du déclencheur (donc il faut que l'entité soit dans l'état testé depuis suffisamment longtemps avant le déclencheur).
• On peut même spécifier plusieurs états champ: Etat, Si le booléen "mode automatique" est activé ou indisponible , Si le tarif tempo est "rouge" ou "blanc".
• On peut également faire tout ce qu'on vient de voir précédemment avec un attribut d'une entité champ: Attributet non plus l'état de l'entité elle-même : Si la température cible du chauffage est supérieure à 24°C, Si la luminosité de l'ampoule est inférieure à 50%, Si la vitesse de ventilation est "auto", etc..

Si vous connaissez bien vos entités, cette condition sera votre meilleure amie, et pour en savoir plus sur les états de vos entités faites un tour dans les outils de développement, onglet Etat :

La condition Appareil (device)

Comme pour le déclencheur du même nom, la condition appareil semble pratique pour débuter, car elle est très simple et naturelle à utiliser :

On choisit un appareil, et elle nous propose des conditions associées, une interface peut être un peu plus simple que les conditions entités.

Mais comme pour le déclencheur, elle possède le même défaut majeur par rapport à la condition "Entité" : Les deux conditions font exactement la même chose, mais la condition "Appareil" est illisible en YAML.

La condition "Heure et lieu"

• La condition Heure (time) : elle vérifie qu'on est dans la bonne plage horaire et l'on peut également spécifier des jours de la semaine définis, On peut utiliser des heures fixes ou des entités donnant une heure (réveils, horaires, etc...) . À utiliser pour restreindre une automatisation à certaines plages horaires fixes, par exemple empêcher une automatisation de se produire avant 9h les weekends :

• La condition Soleil (sun) : fait référence au lever ou au coucher du soleil, éventuellement avec un décalage (note on peut faire la même chose avec une condition entité et l'entité sun.sun) : à utiliser pour des automatismes de volet, de lumière, d'arrosage, etc...

• La condition de Zone (zone) : teste la présence d'une entité de personne ou un device-tracker (votre téléphone, par exemple) dans d'une zone géographique définie dans Home Assistant. À combiner éventuellement avec un bloc "PAS" pour tester l'absence d'une personne dans une zone...

Les autres conditions

• La condition ID, déclenché par (trigger) : Nous le verrons dans le troisième article, il vous permettra de combiner plusieurs automatisations simples en une automatisation complexe. Mais ne brûlons pas les étapes.
• La condition Modèle (template) : Comme pour le déclencheur du même nom, elle permet de conditionner l'automatisation en utilisant un modèle au format JINJA2 qui peut contenir une logique complexe qui combine plusieurs états ou attributs d'entités.

N'oubliez pas, comme vu à l'article précèdent qu'on peut tester ses conditions depuis l'interface :

Et pour tester vos modèles plus facilement, faites un tour dans les outils de développement, onglet Modèle :

Nouveauté depuis 2025.12 : Les conditions par cible

Exactement comme pour les déclencheurs, les conditions aussi bénéficient de cette nouvelle façon de définir les automatisations. Attention c'est encore en développement et cela risque donc d'évoluer (les traductions ne sont pas encore toutes disponibles en français, le nombre de domaines disponibles est en augmentation d'une version à l'autre).

Si on a activé le mode dans "Labs" comme montré dans l'introduction, l'interface des conditions est devenue :

Il y a donc désormais trois onglets : Cibles, Conditions et Blocs, ce qui signifie que l'on va pouvoir, comme pour les déclencheurs, créer les conditions de deux façons, soit par cible, soit par type de conditions.

Commençons par l'onglet conditions :

On observe l'apparition d'une nouvelle condition : "Lumière".

• "If a light is on" : Si une ou plusieurs lumières sont allumées
• "If a light is off" : Si une ou plusieurs lumières sont éteintes

Par exemple pour les lumières allumées :

On voit qu'il y a deux options :

• all : Si toutes les lumières ciblées sont allumées
• any : Si n'importe laquelle des lumières ciblées est allumée

Il nous reste donc à définir des cibles pour finir notre condition, exactement comme pour les déclencheurs, en cliquant sur "+ ajouter une cible".

L'autre manière de définir cette condition par zone est de le faire par cible :

• par exemple par Zone, étage ou pièce (floorou area). Si dans l'onglet Cibles, vous sélectionnez une zone, l'interface vous donnera toutes les conditions disponibles pour cette zone :

En sélectionnant Lumière, vous retrouvez l'interface précédente, puisque au final c'est le même type de condition, que l'on peut sélectionner via le type ou via les cibles.

Vous pouvez ainsi conditionner une automatisation à ne s'exécuter que si au moins une lumière de votre salon est allumée, sans devoir créer un groupe ou lister les entités une par une.

• Ou alors par Étiquettes (labels) : Le système gère également les étiquettes pour cibler des groupes d'appareils (ex : vérifier l'état de toutes les lumières avec l'étiquette "Éclairage d'Ambiance" ou "Éclairage de Noël"), et de la même façon que pour le ciblage par zone, ajouter ou retirer cette étiquette sur une lumière la prendra en compte dans la condition sans avoir besoin de mettre à jour l'automatisation.

Ces conditions par cibles ne sont pour l'instant disponibles que sur le domaine des lumières. Mais elles vont continuer à évoluer avec l'apparition de nouvelles conditions et de nouveaux domaines, la traduction en français, et peut-être des évolutions d'interface.

Bilan

Nous avons donc un panel extrêmement varié de déclencheurs disponibles pour lancer nos automatisations et la capacité de définir très précisément les conditions dans lesquelles on va vouloir que l'automatisation s'exécute. Tout ceci va nous permettre de choisir avec précision quand les actions doivent s'exécuter.

Il est donc grand temps de passer au cœur de l'automatisation : les actions, pour faire un peu plus que simplement allumer notre première ampoule.

Actions : aller au-delà du simple ON/OFF

Les actions sont réellement le moteur de notre automatisation. C'est une évidence ou un pléonasme, mais ce sont bien les actions qui vont permettre à Home Assistant de réaliser des choses à votre place, et comme leur nom l'indique, d'agir.

Dans le premier article, nous avons allumé une lumière. Nous allons voir que les actions peuvent être beaucoup plus variées et sophistiquées.

Avant même d'activer le mode ciblage dans Labs, nous disposons de nombreuses actions, mais aussi (comme pour les conditions) d'un onglet "Blocs" :

Commençons aussi par ces fameux blocs, car ce ne sont pas les mêmes que pour les conditions.

Les blocs et la séquence d'action

L'onglet "Blocs" nous permet de modifier la séquence d'action. Par défaut, si on ajoute plusieurs actions, elles vont se placer les unes en dessous des autres dans l'interface et elles seront réalisées les unes après les autres (dès qu'HA a fini une action, il passe à la suivante). Les blocs vont nous permettre de changer cette manière de fonctionner.

Il existe de très nombreux blocs, dans l'interface, chacun a une petite description vous rappelant son utilité :

• le bloc "Arrêter" (stop) : Il permet de stopper l’exécution de l'automatisation. Ceci peut être utile dans certains cas (après un test conditionnel par exemple) on peut s'en servir pour générer un message d'erreur, par exemple pour arrêter la séquence d'actions si une condition particulière n'est pas remplie dans un cas précis, ou un capteur est indisponible.

• le bloc "attendre que le temps passe (délai)" (delay) : Il permet de patienter dans la séquence durant un temps fixe défini dans le bloc. La séquence va donc se mettre en pause, puis reprendre après le temps défini. Par exemple pour laisser le temps à un équipement qu'on vient de mettre sous tension de démarrer avant de lui donner un ordre de pilotage, ou pour créer une minuterie (allumer une lumière, attendre 5min puis l'éteindre).

• le bloc "attendre un déclencheur" (wait_for_trigger) : Il permet de patienter durant la séquence pour attendre un déclencheur (ou plusieurs), durant un temps fixe défini dans le bloc (facultatif). Après le temps défini, suivant le choix effectué dans le bloc, la séquence peut continuer ou s'arrêter. Si le déclencheur se produit (durant le temps imparti), la séquence se poursuit. Par exemple pour attendre un événement avant de poursuivre des actions, allumer une lumière, attendre qu'un détecteur de présence ne détecte plus de présence, puis éteindre la lumière.
  On ajoutera les déclencheurs, exactement de la même façon que les déclencheurs de l’automatisation, en cliquant sur le bouton bleu clair dans le bloc "+ ajouter un déclencheur".

• le bloc "attendre un modèle" (wait_for_template) : Comme pour le bloc "attendre un déclencheur", il attendra que le modèle au format JINJA2 soit vrai avant de poursuivre. Comme pour le bloc précédent, on pourra définir un temps fixe (facultatif), et faire le choix si la séquence doit continuer ou s'arrêter après l'attente. Si le modèle devient vrai (durant le temps imparti), la séquence se poursuit. Voir les déclencheurs modèles pour les avantages offerts par les modèles par rapport aux déclencheurs "classiques", c'est pareil ici.

• le bloc "choisir" (choose) : C'est l'un des blocs les plus utiles si vous voulez réaliser des actions complexes. Il permet de créer des "aiguillages" dans votre séquence d'action en mode "si, alors", par exemple : S'il fait jour, faire A, sinon faire B.
  Nous allons détailler un peu son fonctionnement, car il va vous être extrêmement utile.

Le bloc choisir en lui-même ne contient rien lorsqu'on clique dessus :

Mais tout se passe dans la séquence d'action :

Un bloc choisir contiendra des options, et éventuellement des actions par défaut. À la création du bloc, il y a une option (l'option 1), vide (on ajoutera d'autres options avec le bouton "+ ajouter une option").

Si on clique sur cette option 1 on "déplie" l'affichage :

on voit qu'une option sera constituée par :

• une ou plusieurs conditions exactement sur le même modèle et la même interface que les conditions de l'automatisation vue plus haut (y compris des blocs et des enchainements complexes de conditions si nécessaire).
• une ou plusieurs actions, exactement sur le même modèle et la même interface que nous sommes en train de détailler (y compris d'autres blocs, y compris d'autres blocs "choisir" imbriqués si nécessaire).

À l'intérieur d'une Option, un peu comme une automatisation :

• si les conditions sont toutes vraies, les actions seront alors effectuées en séquence.
• Si toutes les conditions ne sont pas vraies, on passe à l'option suivante

Et on va continuer ainsi une option après l'autre (on peut mettre autant d'option qu'on veut)

• S'il n'y a plus d'option, on réalise les actions par défaut facultatives
• Et enfin, on passe à la suite de la séquence
  

Exercice pratique, trouverez-vous ce qui cloche dans le bloc ci-dessous qui va allumer ou éteindre notre ampoule du premier article en fonction de l'état du soleil et d'un détecteur de mouvement ?

Solution : vu l'ordre des options 2 et 3, l'option 3 ne sera jamais effectuée, car si elle est vraie (il fait nuit et il n'y a personne), alors la 2 l'est aussi (il fait nuit) donc si on veut utiliser cette subtilité, il faut réorganiser les options pour les réordonner.

Heureusement, on peut faire ça en "agrippant" avec la souris les deux barres horizontales pour bouger l'option 3 et l'amener au-dessus de l'option 2 :

On peut bien sûr "étendre" ou "compacter" tout ou partie des options ou des blocs en cliquant sur les flèches à gauche de chaque bloc ou option :

• le bloc "Condition" (condition) : Il permet d'ajouter une condition (comme celles vues depuis le début de cet article) au milieu de la séquence. Si cette condition n'est pas vraie, l'automatisation s'arrête, et les actions qui suivront le bloc condition ne seront donc pas effectuées. À l'usage, il faut le comparer avec le bloc choisir ci-dessus qui offre plus de capacités, mais parfois la simplicité d'un bloc condition est suffisante.
• le bloc "Définir des variables" (variables) : Il permet de définir des variables locales (c'est-à-dire des nouvelles entités) que vous pourrez utiliser dans toute la séquence d'action (mais uniquement dans la séquence d'action, et durant le temps de l'exécution de l'automatisation). Par exemple un compteur pour compter des éléments puis l'annoncer dans une notification, ou pour réaliser des calculs complexes, un texte que vous modifierez au fur et à mesure de la séquence d'action.
  Ce bloc s'utilise uniquement en YAML. Nous verrons dans le troisième article une alternative (disponible en interface graphique) avec les entrées (helpers en VO) qui elles sont utilisables à la fois dans les déclencheurs, dans les conditions et dans la séquence d'action, mais également en dehors de l'automatisation.
• le bloc "exécuter en parallèle" (parallel) : Il permet de réaliser plusieurs actions en parallèle au lieu de les réaliser en séquence. Si vous avez besoin que certaines actions soient simultanées.
• le bloc "exécuter en séquence" (sequence) : Il permet de réaliser plusieurs actions séquence. Vu que c'est le mode par défaut, j'avoue n'avoir jamais utilisé ce bloc, mais il peut trouver sa place imbriquée dans un bloc "exécuter en parallèle".
• les blocs "répéter" (repeat) : Ils permettent de définir des actions à exécuter en boucle (séquence d'action à répéter) :
  • jusqu'à ce qu'une condition devienne vraie, pour le bloc "répéter jusqu'à ce que" (until)
  • jusqu'à ce qu'on ait fait le nombre de répétitions prévues, pour le bloc "répéter plusieurs fois" (count)
  • jusqu'à ce qu'on ait parcouru l'ensemble des éléments d'une liste, pour le bloc "répéter pour chaque" (for_each)
  • tant qu'une condition reste vraie, pour le bloc "répéter tant que" (while)
• le bloc "si alors" (if then) : c'est une version simplifiée du bloc "choisir" qui n'offre en fait qu'une seule option, si vous êtes à l'aise avec le bloc "choisir", il vous permettra de rajouter une option plus facilement si nécessaire en cours de route.

Tous ces blocs nous permettent de modifier la séquence d'action, la mettre en pause, créer des branches conditionnelles, mais pour l'instant, tous nos exemples n'ont fait qu'allumer ou éteindre une ampoule... Il est temps de voir un peu ce que l'on peut faire dans cette séquence !

Les actions de base, pour agir directement sur votre domotique

Chaque intégration apportera son lot d'actions spécifiques. En fonction des intégrations et des équipements connectés à votre Home Assistant, vous bénéficierez d'un nombre grandissant d'actions possibles. Étudiez la documentation de vos différentes intégrations pour voir quelles sont les actions disponibles. Ce sont ces actions qui vous permettront d'agir sur votre maison !

Vous pouvez parcourir l'ensemble des actions disponibles via les outils de développement pour avoir une idée de la variété des actions disponibles chez vous, les lancer et explorer leurs paramètres :

Nous allons parcourir ensemble quelques grands classiques de quelques intégrations phares.

• Allumer, éteindre et basculer
  De très nombreuses intégrations présentent ces trois actions, parfois simplement, parfois avec des options spécifiques, comme par exemple "allumer" qui pour certaines lumières permet de définir la couleur ou la puissance. Pour toutes les intégrations présentant un état "ON" et un état "OFF":
  • "allumer" (turn_on) passera les éléments à l'état "ON" (éventuellement avec des options spécifiques comme la luminosité ou la couleur pour les lumières par exemple)
  • "éteindre" (turn_off) passera les éléments à l'état "OFF"
  • "basculer" (toggle) changera l'état des éléments commandés (donc passera les éléments de l'état "OFF" à "ON" ou de "ON" à "OFF" suivant l'état initial)

• Ouvrir, fermer, basculer, arrêter, régler pour des ouvertures (volets par exemple, mais aussi portail, pergola, stores par exemple)
  Les intégrations d'ouverture présentent ces actions, et parfois aussi des actions équivalentes concernant l'orientation des lames pour des stores ou des pergolas.
  • "ouvrir" (open_cover) ouvre complètement le volet
  • "fermer" (close_cover) ferme complètement le volet
  • "basculer" (toggle) bascule entre fermé et ouvert suivant l'état initial
  • "arrêter" (stop_cover) arrête le mouvement du volet
  • "régler la position" (set_cover_position) règle le volet sur la position spécifiée dans l'action (si le volet le permet).
• Définir, Incrémenter ou décrémenter une valeur numérique pour un compteur (couter) ou un nombre (input_number) ou Définir la valeur d'un texte (input_text) ou encore sélectionner dans une liste prédéfinie (input_select):
  • "Définir" (set_value) pour donner une valeur directement à une entité ou "Sélectionner" (select_option) pour choisir dans une liste prédéfinie
  • "Incrémenter" (increment) pour ajouter "1" à un nombre ou un compteur
  • "Décrémenter" (decrement) pour retirer "1" à un nombre ou un compteur
• définir un mode (set_hvac_mode) : par exemple sur une entité thermostat (climate), on va avoir suivant votre modèle la capacité à définir le mode (chauffage, climatisation, déshumidification, etc...) mais aussi la vitesse de ventilation, la température cible, le mode d'oscillation, etc...
• Démarrer, arrêter, suspendre (start, stop, pause) : les entités proposant ces actions (par exemple un media player, mais aussi un aspirateur robot ou une tondeuse robot, qui proposeront aussi d'autres actions comme rentrer à la base...
• Envoyer une notification (notify) : Cette action va être très pratique pour que votre maison se mette à vous parler. Il existe de nombreuses manières, en fonction de vos intégrations, de réaliser ceci:
  • envoyer une notification persistante (notify.persistent_notification en VO) pour envoyer une notification dans votre interface home assistant (titre, message et données facultatives):

• envoyer une notification sur un mobile ayant l'appli companion installé (notify.mobile_app_xxx)
• envoyer une notification vers une enceinte connectée pour diffuser un message vocal dans la maison, par exemple avec Alexa media player (HACS) : (notify.alexa_media_echo_dot) (chaque type d'enceinte connectée propose ce mécanisme, pas uniquement Alexa)
• Tout autre moyen dont vous pourriez disposer (SMS, Télégram, etc...)

Des actions plus spécialisées encore, c'est possible ?

Oui bien sûr, pour cela, il va falloir étudier les capacités de votre domotique pour aller encore plus loin, ou mettre un peu le nez dans le code. Quelques exemples :

• Actions enrichies : Les actions que l'on vient de voir peuvent très souvent être enrichies avec des templates au format JINJA2, pour remplacer un texte ou une valeur, et parfois plus encore.
  • Un texte peut être modifié avec un modèle (template) pour inclure du contenu issu de votre domotique, soit dans un input_text, soit dans une notification, par exemple : Il fait {{ states('sensor.temperature_salon') }}°C dans le salon
• Une valeur peut être remplacée par un modèle (template) pour utiliser une valeur dynamique, ou réglable ou le résultat d'un calcul, plutôt qu'une valeur fixe dans vos automatisations, par semple au lieu de régler la température cible d'un chauffage sur une valeur fixe, la régler sur la valeur d'un input_number (nous en reparlerons dans le troisième article)

Pour aller plus loin, certaines intégrations vous proposeront des actions qui peuvent élargir encore vos capacités :

• Actions spook (disponible dans HACS, le store communautaire), vous permettent d'agir sur Home assistant lui-même, en ajoutant des actions génériques et des entités qui peuvent s'avérer bien pratiques, par exemple pour activer ou désactiver des intégrations, redémarrer votre Home assistant.
• Vos intégrations : étudiez la doc et les capacités de vos intégrations pour savoir tout ce que vous pouvez faire. Cette liste déjà longue n'est pas exhaustive !
• Ne négligez pas les notifications : parfois la meilleure action, c'est la vôtre. Et votre maison peut vous aider à penser à faire des choses que vous ne pouvez pas automatiser à 100% : vous avertir qu'il fait chaud dedans et frais dehors et qu'il est intéressant de ventiler, vous faire penser à arroser vos plantes ou à sortir la bonne poubelle.

Nouveauté depuis 2025.12 : Les actions par cible

Exactement comme pour les déclencheurs et les conditions, les actions aussi bénéficient de cette nouvelle façon de définir les automatisations. Attention c'est encore en développement et cela risque donc d'évoluer (les traductions ne sont pas encore toutes disponibles en français, le nombre de domaines disponibles est en augmentation d'une version à l'autre).

Activez le mode dans le Labs comme montré dans l'introduction et observez comment vous pouvez définir des actions par cible, par entité, par appareil, par zone ou encore par étiquette. Je pense qu'après tout cet article, vous arriverez à découvrir tout ça tous seuls. Si vous n'êtes pas sûrs de vous, retournez voir comment ça se passe pour les déclencheurs et les conditions, les manières de faire et les interfaces sont similaires.

Cas pratiques

Pour illustrer cet article, je vous propose d'étudier deux automatisations un peu plus complexes que l'allumage automatique du premier article, je vous propose les exemples suivants, dans lesquels la complexité va résider à des niveaux variés :

• pour la première : c'est l'articulation déclencheurs / conditions dans laquelle va résider toute l'astuce.
• pour la seconde : c'est la séquence d'action qui présentera un peu plus de subtilités.

Exemple avec utilisation de déclencheurs et conditions multiples

Pour ce premier exemple, je vous propose de réfléchir au besoin suivant:

Pour la dernière ligne, c'est simple, on va ajouter une condition sur un booléen (input_boolean) que l'on pourra facilement piloter depuis le dashboard, via des automatisations ou en vocal. Si on utilise le même booléen dans diverses automatisations, on pourra toutes les piloter ensemble.

Pour le reste, une manière de faire pourrait être de mettre un déclencheur 10 min avant le lever du soleil avec le déclencheur "soleil" :

Puis de jouer sur des blocs d'action "attendre un modèle" ou des blocs "choisir" en fonction des conditions pour attendre que l'heure mini soit atteinte, et alors réaliser l'action d'ouverture. Mais, en plein été avec un lever de soleil vers 6h, on risque de garder l'automatisation "en suspens" plusieurs heures jusqu'à 9h30 le week-end. Ce n'est pas idéal.

On va donc faire les choses différemment, avec des conditions bien choisies, pour vérifier toutes les conditions nécessaires :

Pour l'heure, dans un bloc "OU", on va tester la condition "heure" après notre heure fatidique en testant bien les jours qui nous intéressent :

Pour le mode automatique une condition "Etat" sur notre booléen :

Et ne pas oublier de vérifier que l'on est bien plus tard que 10 min avant le lever de soleil, avec une condition "Soleil" :

Ce qui nous donne les conditions suivantes (en YAML):

conditions:
  - condition: state
    entity_id: input_boolean.volet_roulant_auto
    state: "on"
    alias: Mode Auto volet roulant = ON
  - condition: or
    conditions:
      - condition: time
        after: "07:10:00"
        weekday:
          - mon
          - tue
          - wed
          - thu
          - fri
      - condition: time
        after: "09:30:00"
        weekday:
          - sat
          - sun
  - condition: sun
    after: sunrise
    after_offset: "-00:10:00"
    alias: Plus tart que 10min avant lever du soleil

Une telle condition n'est vraie que dans les cas qui nous intéressent :

• après le lever de soleil (même 10 min avant celui-ci)
• après nos heures limites (avec le week-end pris en compte)
• si le mode auto est activé

Il nous suffit donc d'un déclencheur pertinent pour pouvoir lancer notre intégration au bon moment.

• On pourrait être brutal et lancer cette automatisation avec un déclencheur "modèle de temps" toutes les minutes, tous les matins, entre 6h et 9h31, pour trouver le moment où ces conditions deviennent vraies...
• On pourrait recréer cette logique de conditions dans un modèle (template) et déclencher lorsque ce modèle devient vrai (on n'aurait alors en pratique plus besoin des conditions dans ce cas).
• On va être plus fin et déclencher seulement sur les éléments qui entrent dans cette logique : il nous suffit de tester cette condition à trois ou quatre moments clefs :
  • 10 min avant le lever de soleil (si la condition est vraie, on ouvre pour le lever de soleil s'il a bien lieu après les heures mini)
  • à 7h10 en semaine (si la condition est vraie, on ouvre pour 7h10 en semaine si le soleil s'est levé plus tôt)
  • à 9h30 les week-ends (si la condition est vraie, on ouvre pour 9h30 en week-end si le soleil s'est levé plus tôt)
  • en bonus, on peut aussi trigger si le booléen devient vrai, mais c'est facultatif (dans notre cas, c'est peu utile, mais pour certaines logiques, c'est très pratique, par exemple pour lancer un chauffage lorsque vous activez le mode auto).

On obtient donc les déclencheurs suivants en YAML :

triggers:
  - trigger: sun
    event: sunrise
    offset: "-00:10:00"
  - trigger: time
    at: "07:10:00"
    weekday:
      - mon
      - tue
      - wed
      - thu
      - fri
  - trigger: time
    at: "09:30:00"
    weekday:
      - sat
      - sun

L'automatisation sera donc déclenchée chaque jour deux fois :

• 10 min avant le lever du soleil
• a l'heure limite

et à chaque déclenchement, si un des éléments de la condition n'est pas vérifié, l'automatisation s'arrêtera. Elle ne continuera que si toutes les conditions sont vérifiées.

Il ne reste donc plus qu'à ajouter une simple action d'ouverture des volets et notre automatisation ouvrira les volets dans les conditions souhaitées.

Voici le code complet. Vous pouvez le copier-coller, les seules parties spécifiques étant l'entité des volets (mon groupe de volets pilotant tous les volets) et le booléen mode auto, qu'il faudra adapter à votre installation.

alias: Volets - ouverture auto
description: >-
  En mode auto, les volets s'ouvrent 10 min avant le lever du soleil
  (mini 7h10 en semaine et 9h30 le WE).
triggers:
  - trigger: sun
    event: sunrise
    offset: "-00:10:00"
  - trigger: time
    at: "07:10:00"
    weekday:
      - mon
      - tue
      - wed
      - thu
      - fri
  - trigger: time
    at: "09:30:00"
    weekday:
      - sat
      - sun
conditions:
  - condition: state
    entity_id: input_boolean.volet_roulant_auto
    state: "on"
    alias: Mode Auto volet roulant = ON
  - condition: sun
    after: sunrise
    after_offset: "-00:10:00"
    alias: Plus tart que 10min avant lever du soleil
  - condition: or
    conditions:
      - condition: time
        after: "07:10:00"
        weekday:
          - mon
          - tue
          - wed
          - thu
          - fri
      - condition: time
        after: "09:30:00"
        weekday:
          - sat
          - sun
    alias: Plus tart que 7h10 en semaine et 9h30 le WE
actions:
  - action: cover.open_cover
    target:
      entity_id:
        - cover.tous_les_volets
    data: {}
mode: single

Exemple avec séquence d'action plus complexe

Pour ce second exemple, je vous propose de réfléchir au besoin suivant :

Pour la dernière ligne, c'est simple, on va ajouter une condition sur un booléen (input_boolean) que l'on pourra facilement piloter depuis le dashboard, via des automatisations ou en vocal. Si on utilise le même booléen dans diverses automatisations, on pourra les piloter toutes ensemble et ne pas avoir de notification en mode silence...

Il nous faut donc un déclencheur pertinent pour pouvoir lancer notre intégration au bon moment.

• On va étudier la puissance fournie par notre prise électrique lors d'un cycle de lavage pour déterminer quelle transition utiliser pour notre déclencheur :

Mon Lave-linge ne passe jamais sous 5W durant plus d'une minute durant son cycle, il suffit donc de déclencher sur la valeur numérique :

Et l'on déclenchera l'automatisation 5 min après la fin du cycle, et pas en cours de cycle (on pourra abaisser cette temporisation, en faisant des tests sur la valeur du seuil et la durée de confirmation, pour essayer de réduire la durée au maximum sans avoir de déclenchement intempestif durant le cycle, je suis à 30s par exemple)

triggers:
  - trigger: numeric_state
    entity_id:
      - sensor.lave_linge_power
    for:
      hours: 0
      minutes: 5
      seconds: 0
    below: 5

Pour les conditions, je ne vais pas en mettre, car je souhaite que l'intégration se déroule de façon systématique, avec des notifications variées, dont certaines silencieuses.

Pour les actions, nous allons les définir au fur et à mesure ensemble :

• Tout d'abord une notification silencieuse, ceci pourrait être l'allumage d'une veilleuse indiquant qu'il y a une action à faire par exemple, ou un booléen affiché sur le tableau de bord. Dans notre exemple, nous activerons un input_boolean, qui pourra donc être affiché dans le dashboard pour indiquer que la machine est "à vider" (il faudra donc penser à un moyen de le réinitialiser, par exemple une automatisation si le sèche-linge démarre, si le lave-linge démarre, ou via un appui sur un bouton dédié, ou encore via le dashboard, à vous de voir) :

• Ensuite une (ou plusieurs suivant le nombre de personnes concernées dans la maison) notifications sur le téléphone mobile, celles-ci pouvant être mises en silencieux sur le téléphone lui-même, pas besoin de condition.

Et si on veut aller plus loin, on peut introduire un modèle pour avoir l'heure de fin du lave-linge dans le texte de la notification :

Le lave linge s'est terminé à {{ as_timestamp(now())|timestamp_custom('%-Hh%M') }}, penser à le vider !

• Une notification audio sur une enceinte connectée (Alexa chez moi) :
  ici, nous allons ajouter un bloc "choisir" pour changer la notification en fonction de l'heure, en effet, Alexa propose un mode chuchotement qui sera parfait pour la nuit, nous ajouterons dans la condition que le mode silencieux doit être désactivé :

• Pour finir, nous avons aussi un Sèche-linge. Cette partie est optionnelle, mais dans notre cas, lorsqu'on enchaine les machines, il n'est pas nécessaire de se précipiter pour vider la machine si le Sèche-linge n'est pas fini. Nous avons donc une autre automatisation qui détecte le fonctionnement du sèche-linge et qui pilote un booléen "séchage en cours".
  Nous pouvons alors ajouter un autre bloc choisir, et le mettre en tout début de séquence :
  • Si le sèche-linge ne tourne pas, on passe directement à la suite
  • Si le sèche-linge tourne, on attend qu'il se termine avant de passer à la suite de la séquence
    

Voici le code complet. Vous pouvez le copier-coller, pour l'observer chez vous, et utiliser ce modèle pour domotiser un lave-linge, un sèche-linge, ou un lave-vaisselle, avec une simple prise connectée qui mesure la puissance (une par appareil).

alias: HACF - Notification Lave linge
description: |-
  Envoie des notifications à la fin du lave linge (ou du seche linge):
  - booléen dashboard
  - notification mobile
  - annonce vocale (en fonction de l'heure)
triggers:
  - trigger: numeric_state
    entity_id:
      - sensor.lave_linge_power
    for:
      hours: 0
      minutes: 5
      seconds: 0
    below: 5
conditions: []
actions:
  - choose:
      - conditions:
          - condition: state
            entity_id: input_boolean.sechage_en_cours
            state: "off"
        sequence: []
      - conditions:
          - condition: state
            entity_id: input_boolean.sechage_en_cours
            state: "on"
        sequence:
          - wait_for_trigger:
              - entity_id:
                  - input_boolean.sechage_en_cours
                from: "on"
                to: "off"
                trigger: state
  - action: input_boolean.turn_on
    metadata: {}
    target:
      entity_id: input_boolean.machine_a_vider
    data: {}
  - action: notify.mobile_app_pixel_7a
    metadata: {}
    data:
      title: Machine terminée
      message: >-
        Le lave linge s'est terminé à {{
        as_timestamp(now())|timestamp_custom('%-Hh%M') }} penser à le vider !
  - choose:
      - conditions:
          - condition: time
            after: "20:00:00"
            before: "09:00:00"
          - condition: state
            entity_id: input_boolean.mode_silencieux
            state:
              - "off"
        sequence:
          - data:
              message: >-
                <amazon:effect name="whispered">La machine à laver est
                terminée</amazon:effect>
              target:
                - media_player.echo_dot
                - media_player.echo
              data:
                type: tts
              title: Annonce lavage fini chuchotté
            action: notify.alexa_media
      - conditions:
          - condition: time
            after: "09:00:00"
            before: "20:00:00"
          - condition: state
            entity_id: input_boolean.mode_silencieux
            state:
              - "off"
        sequence:
          - data:
              message: >-
                <prosody volume="soft">La machine à laver est termninée, vous
                pouvez la mettre au sèche linge</prosody>
              target:
                - media_player.echo_dot
                - media_player.echo
              data:
                type: tts
              title: Annonce lavage fini
            action: notify.alexa_media
mode: single

Conclusion : À vous de jouer...

Vous avez désormais toutes les clés en main pour créer des automatisations complexes. De la gestion simple d'un éclairage, on est passé à des scénarios multi-étapes déclenchés de façon fine, dans les circonstances que vous aurez parfaitement choisies, et qui interagissent avec l'ensemble de vos intégrations.

Vous êtes donc prêt à exploiter toute la puissance de votre Home Assistant ! N'hésitez pas à explorer les possibilités offertes par vos intégrations. Faites des recherches dans l'interface, observez vos entités et leurs attributs, échangez sur le forum si vous êtes coincés.

Et si vous voulez continuer à approfondir le sujet, améliorer vos automatisations et fiabiliser votre système, rendez-vous pour l'article suivant : Automatisation #3 : aller encore plus loin ! (à venir).