Automatisation #3 : aller encore plus loin !

Bienvenue dans ce troisième article de la série. Vous êtes passés de la première ampoule qui s'allume seule aux scénarios les plus sophistiqués. Nous allons aborder les derniers détails, pour vous permettre de vraiment exploiter toutes les possibilités offertes par Home Assistant, d'optimiser le fonctionnement de vos automatisations et surtout de pérenniser leur maintenance.

Pour commencer

Cet article va plonger dans les dernières subtilités offertes par les automatisations, afin de les rendre plus efficaces, plus performantes, plus robustes et plus faciles à maintenir sur le long terme.

Rappels des bases

Si vous n'avez pas encore lu les deux premiers articles : Automatisation #1 : débuter en douceur ! et Automatisation #2 : libérer le plein potentiel ! c'est le moment de le faire !

Pour mémoire, toute automatisation repose sur trois éléments fondamentaux : déclencheurs, conditions et actions. Avoir compris cette trilogie est indispensable pour maîtriser Home Assistant. Nous avons vu ces grands principes dans le premier article, puis l'impressionnante variété de déclencheurs, de conditions et d'actions disponibles dans le deuxième article de cette série.

Dans cette dernière partie, nous abordons les outils qui permettent d'organiser, de fiabiliser et d'améliorer les performances de vos automatisations, sans revenir sur les notions déjà abordées.

Organisez et documentez pour une meilleure maintenance à long terme

Commençons avec des règles simples, mais de bon sens. En informatique, un code facile à lire est un code bien documenté. L'interface graphique de Home Assistant facilite beaucoup de choses au début, mais n'est pas forcément la plus efficace pour inviter à ajouter des commentaires.

L'idée dans ce chapitre va être de vous projeter dans l'avenir et de penser à votre futur "vous". Aujourd'hui, vous êtes en train de créer ou de modifier votre code, toutes les subtilités vous semblent évidentes. Mais qu'en sera t'il dans deux ou trois ans ? Lorsque vous aurez une liste d'automatisations approchant ou dépassant la centaine? (Certaines en test, ou de petits gadgets rigolos, mais aussi certaines vraiment critiques comme la gestion du chauffage, de l'alarme ou de vos serrures connectées).

Comment s'y retrouver ? Prenez de bonnes habitudes dès le début !

Nommez avec méthode et ajoutez une description utile.

On l'a vu dans le premier article, on peut donner un nom et une description à chaque automatisation.

Utilisez une stratégie pour leur nom, comme pour vos entités et vos appareils.

• Définissez votre manière de faire dès le début et tenez-vous à cette stratégie, même pour vos tests et gadgets. Qui sait si ce gadget ne va pas durer plusieurs années et finir par devenir indispensable ?
• Le nom doit vous permettre de faire des recherches rapides pour retrouver sans problème ce que vous cherchez
• Le nom ne doit pas être ambigu, par exemple : Domaine - Principale entité ciblée - Action principale

Pour aller plus loin, et que le contenu aussi vous parle, même après plusieurs années sans y toucher, utilisez une description efficace pour ne pas oublier le fonctionnement de vos programmes et vous rappeler toutes leurs subtilités.

• N'hésitez pas à consacrer un peu de temps à la description, pour mettre tous les aspects importants de votre code
• S'il y a des subtilités, des booléens de contrôle, des paramètres particuliers, rappelez le dans la description
• Si vous avez trouvé une astuce particulière inhabituelle, le mentionner ne peut pas faire de mal.

Triez avec Catégories et Étiquettes

L'interface des automatisations (comme celle des scènes et des scripts), vous permet de les grouper de plusieurs façons :

Vous pouvez ainsi utiliser les Catégories pour structurer cette liste et réduire l'affichage en réduisant ou développant ces groupes.

Vous pouvez également leur attribuer autant d' Étiquettes (labels) que vous voulez, pour les filtrer et les organiser selon vos besoins dans cette vue.

Pour attribuer ou modifier une catégorie, ou ajouter une étiquette, plusieurs solutions :

• dans l'interface de modification d'une automatisation, lorsqu'on l'enregistre ou la renomme, on peut définir une catégorie et attribuer une pièce et une ou plusieurs étiquettes :

• dans cette même interface, en cliquant sur les 3 points en haut à droite, on peut définir ou modifier la catégorie :

• Dans les paramètres de l'automatisation, on peut ajouter une ou plusieurs étiquettes :

• Et enfin dans la liste des automatisations, si on les sélectionne avec les cases à cocher, on dispose de 3 boutons en haut à droite pour définir la catégorie, les étiquettes ou la pièce, et on peut en sélectionner autant qu'on veut pour leur appliquer à toutes le même traitement :

Commentez avec les Alias (alias)

Si nous reprenons l'exemple de l'article #2:

Il n'est pas toujours évident avec le nom par défaut des blocs (qui n'est pas disponible en YAML) de comprendre au premier coup d'œil le rôle par exemple des blocs "choisir".

Dans n'importe quel bloc ou action ou étape, on peut la plupart du temps renommer celui-ci pour le rendre plus parlant si nécessaire (alias). Je vous conseille de le faire au minimum pour les blocs "choisir", mais aussi pour le reste si vous en ressentez le besoin :

De plus ces alias se retrouveront aussi dans le YAML, ainsi ils vous faciliteront la lecture et le partage du code.

Créez tout ce qui vous manque avec les entrées (helpers)

On peut créer des variables à l'intérieur de la séquence d'action, avec des blocs "variables" (variable). Mais dans de nombreux cas, il sera encore plus performant de créer des entrées (helper). Ce sont des entités à part entière, que vous définissez vous-même, et avec lesquelles vous pourrez donc interagir, comme n'importe quelle entité de votre domotique.

Vous pourrez les ajouter dans votre tableau de bord, interagir via des actions, des automatisations, vous en servir de déclencheur ou de conditions.

On l'a déjà fait dans les deux articles précédents en utilisant des booléens (input_boolean), on va aller un peu plus loin en observant les possibilités offertes par tous les types d'entrées disponibles.

Les entrées sont très faciles à créer désormais, tout se passe dans l'interface, sans avoir besoin de manipuler les fichiers de configuration en YAML:

Dans les paramètres : cliquez sur "Appareils et services"

Puis sélectionnez l'onglet "Entrées" et cliquez sur "+ Créer une entrée"

Si vous préférez un format vidéo et un tuto pas à pas sur ce point précis, n'hésitez pas à aller jeter un œil sur cette vidéo d'un de nos membres : Lien vers la video du Journal de Thomas

Les interrupteurs (input_boolean), basique à deux états.

Un interrupteur ou booléen est une entité qui prendra deux états : activé ou désactivé. Vous pourrez l'utiliser dans vos automatisations, chaque fois que vous aurez besoin de ce genre de bascule entre deux états, que ce soit en déclencheur, en condition ou en action.

Les booléens pourront être utilisés pour de nombreux cas, par exemple :

• représenter l'état d'un mode ou d'un état piloté manuellement (mode auto des volets, mode silence des notifications, gestion d'un affichage au dashboard)
• représenter l'état d'un équipement non directement domotisé (machine à laver en cours, courrier à récupérer, poubelle à sortir)
• représenter un sensor binaire activé ou calculé par ailleurs (présence détectée, tarif heure pleine, alerte en cours)

La liste déroulante (input_select) pour des choix multiples

Une liste déroulante est une entité qui prendra un nombre d'états défini dans une liste que vous aurez créé vous-même. Vous pourrez l'utiliser dans vos automatisations, chaque fois que vous aurez besoin de ce genre de bascule entre plusieurs états, que ce soit en déclencheur, en condition ou en action.

Les listes déroulantes pourront être utilisées pour de nombreux cas, par exemple :

• représenter l'état d'un mode à choix multiples (mode auto notifications comme dans l'exemple ci-dessus)
• représenter l'état d'un équipement non directement domotisé (quelle poubelle sortir : la bleue, la jaune, aucune, quel est le tarif tempo de demain)
• représenter une liste de choix pour l'utilisateur (choix d'un groupe d'enceintes pour un media player par exemple)
• A vous d'inventer la suite !

Le nombre (input_number) pour des valeurs numériques

Un nombre est tout simplement une entité numérique. Vous pourrez l'utiliser dans vos automatisations, chaque fois que vous aurez besoin d'un nombre, que ce soit en déclencheur, en condition ou en action. Il existe aussi une entrée compteur (counter), au fonctionnement proche (avec des actions spécifiques pour le faire varier de 1, pratique pour compter, comme son nom l'indique).

Les nombres pourront être utilisés pour de nombreux cas, par exemple :

• Paramétrer vos automatisations avec un nombre réglable, celle-ci pourra être modifiée par l'utilisateur en réglant le nombre directement dans le dashboard ou à la voix par exemple plutôt qu'en modifiant l'action dans l'automatisation. Les exemples sont multiples : température cible de chauffage, durée d'arrosage, valeur d'une temporisation. Vous pourrez même calculer ce nombre dans une automatisation (fonction de la météo par exemple).
• représenter l'état d'un équipement non directement domotisé (nombre d'activations d'une surveillance ou d'un équipement, durée d'utilisation d'un équipement) pour l'utiliser dans un dashboard ou dans d'autres automatisations.
• A vous d'inventer la suite !

Le texte (input_text) pour des chaines de caractères

Un texte est tout simplement une entité textuelle, limitée à 255 caractères. Vous pourrez l'utiliser dans vos automatisations, chaque fois que vous aurez besoin d'un texte en clair, que ce soit en déclencheur, en condition ou en action.

Les textes pourront être utilisés pour de nombreux cas, par exemple :

• stocker des évènements issus de vos automatisations (des modes en texte clair "heures pleines" ou "heures creuses" plutôt qu'un booléen par exemple)
• faire passer des informations vers des scripts ou des automatisations (pour des notifications par exemple, ou pour passer une demande de musique vers un média player)
• réaliser du texte évolutif pour l'utiliser dans un dashboard ou dans d'autres automatisations (comme des messages élaborés sur l'emploi du temps des enfants ou des alertes ou des messages de panne)
• mémoriser des valeurs (par exemple des actions sur un bouton) pour réaliser des automatisations de type double clic par exemple.

La planification (scheduler) pour un emploi du temps hebdomadaire

Une planification est une entité de type booléen, qui sera activée suivant un planning hebdomadaire établi. Vous pourrez l'utiliser dans vos automatisations, chaque fois que vous aurez besoin d'un planning à la semaine, que ce soit en déclencheur ou en condition.

Les planifications pourront être utilisés pour de nombreux cas, pour déclencher ou conditionner des automatisations sur un planning préétabli, par exemple pour du chauffage, un planning d'arrosage, une simulation de présence avec de l'éclairage, etc.

Le minuteur (timer) pour maîtriser le temps

Un minuteur est tout simplement une entité qui restera activé un certain temps puis se désactivera automatiquement. Vous pourrez l'utiliser dans vos automatisations, chaque fois que vous aurez besoin d'un délai, que ce soit en déclencheur, en condition ou en action.

Nous verrons un peu plus loin ses intérêts principaux, en particulier si on pense bien à cocher la case "Restaurer l'état et l'heure au démarrage de Home Assistant" !

Les minuteurs pourront être utilisés pour de nombreux cas, par exemple :

• créer un délai dans vos automatisations (allumage automatique, durée avant un reboot, durée avant un changement de mode)
• modifier la durée d'un délai dans une automatisation (on peut changer la durée d'un timer quand on le lance, et donc lancer une pompe de piscine pour une durée qui dépend de la température de l'eau par exemple)
• contrôler la durée du minuteur (on peut le mettre en pause, le relancer, l'annuler, comme on le souhaite, via des actions)
• l'utiliser dans un dashboard ou dans d'autres automatisations (pour afficher l'état du minuteur ou sa date de fin par exemple)
• A vous d'inventer la suite !

Et tant d'autres...

La liste exhaustive des entrées est longue. Nous avons vu les plus courantes, mais il en existe beaucoup. A vous de voir celles qui vous seront utiles, pour créer directement des entités ou combiner l'état d'entités dans une nouvelle entrée :

• des boutons (input_button)
• des dates et/ou heures (input_datetime)
• des modèles (template)
• modifier le type d'appareil d'un commutateur (changer un switch en lumière par exemple)
• des "compteurs de service public" (utility_meter) utilisables dans le dashboard energy par exemple
• des thermostats ou hygrostats génériques (pour contrôler un chauffage à partir d'un interrupteur et d'un capteur de température ou d'humidité)
• des capteurs de seuil, de mini, de maxi, de statistique, des dérivées ou des intégrales...
• Des groupes d'entités (group)

N'oubliez pas les variables...

On a vu dans l'article 2 qu'on pouvait ajouter des blocs "Définir des variables" (variables) dans la séquence d'action. Celles-ci peuvent vous permettre, un peu a la façon des entrées, d'ajouter des entités utiles, par exemple pour réaliser des calculs complexes, élaborer un texte pour une notification, créer une liste, ou pour éviter de répéter plusieurs fois une opération complexe et stocker son résultat pour le réutiliser plusieurs fois.

Contrairement aux entrées vues juste avant, ces variables "n'existeront" que dans la séquence d'action et durant le déroulement de l'automatisation, puis elles "disparaitront" à la fin de la séquence. Elles ne seront pas utilisables ailleurs que dans l'automatisation, et uniquement durant son exécution.

Coder efficacement avec les Scripts et les Scènes

L'interface automatisation comporte 4 onglets, j'aurais pu commencer par les scènes et les scripts dès le premier article, et progresser ainsi par capacité croissante avant d'aborder les automatisations. J'ai choisi de démarrer par les automatisations qui couvrent le plus grand nombre de possibilités.

Il est donc grand temps d'aborder les caractéristiques des autres outils à votre disposition : les scripts et les scènes ! Vous verrez ainsi comment vous pourrez vous en servir, seuls et dans vos automatisations (nous verrons les blueprints plus loin).

La Scène, pour modifier plusieurs entités d'un seul geste

Une scène (scene) représente un état figé d'une ou plusieurs entités. Elle ne peut agir que sur les états des appareils ou des entités qu'elle pilote. Elle ne peut pas faire d'action plus compliquée ou de tests de logique.

Idéale pour définir des ambiances (lumière, couleur, volume) en réglant plusieurs équipements en un seul geste, depuis le dashboard, en commande vocale, ou via une action (dans un script ou une automatisation par exemple).

Par exemple :

• une scène "cinéma" avec les volets fermés, la lumière principale éteinte et les lumières d'ambiances en mode bleu à 10% d'intensité
• une scène "bonjour" avec le volet de la cuisine ouvert à 50%, la prise de la machine à café activée et la lumière de la cuisine allumée à 50%

Le Script, pour des séquences complexes

Le script (script) et l'automatisation sont très proches. En fait un script est une séquence d'action, sans déclencheurs et sans conditions (ou l'inverse, une automatisation, c'est un script muni d'un démarrage automatique, suivant l'explication que vous préférez).

C'est donc une séquence d'action qu'il faudra déclencher "manuellement", ou dans une automatisation, afin de la lancer.

Comme vu au chapitre précédent (pour les automatisations), un script pourra utiliser des entités, y compris des entrées, ainsi que des variables (qui seront locales et utilisables uniquement durant l'exécution du script).

Un script pourra en plus prendre des champs (field) en entrée, afin d'avoir des actions modulables, comme les actions des intégrations.

Dans l'interface du script, on pourra dans le menu en haut à droite cliquer sur ajouter des champs :

ou, si on en a déjà défini au moins un, cliquer sur "+ ajouter un champ" :

Ces champs pourront alors être réutilisés dans la séquence d'action, comme si c'étaient des entités ou des variables, pour des actions, des conditions, etc...

Une fois ajouté des champs, lorsqu'on appellera le script dans une séquence d'action, il faudra renseigner les valeurs des champs afin que le script s'exécute correctement (ils peuvent être obligatoires ou facultatifs, et avoir une valeur par défaut si non renseignée). Par exemple si on crée un script de notification, on pourra définir un champ "titre", et un champ "message". À chaque fois qu'on voudra utiliser notre script, il faudra définir (dans l'interface de l'automatisation, ou en YAML) la valeur du titre et du message à utiliser dans les données (data) du script.

Par rapport à une scène, le script va donc vous permettre d'aller beaucoup plus loin, avec des actions complexes et des blocs pour modifier la séquence d'action (comme vu dans le deuxième article).

par exemple :

• un script mode cinéma qui va fermer les volets seulement s'il fait jour, allumer la lumière en mode bleu 10% et lancer Netflix sur la smart tv si celle ci est éteinte.
• un script de notification qui va envoyer une notification sur les téléphones des parents via la seule commande script.notification_smartphone_parents et les champs associés :

action: script.notification_smartphone_parents
data:
  message: La lessive vient de se terminer, il faut la mettre au sèche linge
  titre: Lessive finie

Écrire moins de code grâce aux scripts et aux scènes

Rien n'interdit (au contraire) d'utiliser des scènes et des scripts dans vos automatisations. C'est même une manière très pratique de réduire la taille de vos codes.

Vous pouvez le faire dès le début ou a posteriori, dès qu'une fonctionnalité risque d'être utilisée plusieurs fois.

Ceci présente de multiples avantages :

• moins de code à écrire puisque vous allez réutiliser une séquence complète déjà écrite plutôt que de la réécrire à chaque fois (moins de fatigue, moins de risque d'erreur, un code plus simple à lire).
• une maintenance plus facile puisque si vous avez une modification à faire dans cette séquence (par exemple un nouveau téléphone à intégrer dans une séquence de notification) il suffira de faire cette modification une seule fois dans le script pour qu'elle soit automatiquement prise en compte dans toutes les automatisations qui l'utilisent (plutôt que de faire la modification à chaque endroit où cette séquence est répétée).
• De multiples moyens d'utiliser ce code en appelant la scène ou le script : dans le dashboard, en commande vocale, via des automatisations, votre travail devient réutilisable et diffusable partout dans votre domotique.

Cas pratique : des notifications dynamiques

Plutôt que d'essayer de refaire ici un exemple pratique, je vous propose de regarder cet article :

Notifications dynamiques en fonction de la pièce occupée

Vous avez plusieurs assistants vocaux et ne voulez pas qu’ils se déclenchent systématiquement dans toutes les pièces ? Voici comment gérer des notifications intelligentes dans la maison en fonction de la présence ou non des personnes dans les différentes pièces.

Home Assistant Communauté FrancophoneGael

Celui-ci décrit parfaitement les avantages du script : avec un script de notification particulièrement élaboré pour avoir la diffusion d'un message uniquement dans les pièces occupées. Ce script peut ensuite être utilisé tel quel dans toutes les automatisations pour lesquelles on va vouloir réaliser ce même type d'annonce :

• annonces automatiques dans une automatisation avec des triggers et conditions bien choisies (par exemple : fin de lave-linge, fenêtre oubliée ouverte, problème sur le congélateur, quelqu'un sonne à la porte, etc...)
• utilisation directe du script, par exemple dans un dashboard pour des annonces prédéfinies ("tout le monde à table", "le film va commencer") via un simple appui sur un bouton du dashboard.

La mise à jour d'un élément (par exemple une nouvelle enceinte connectée, un nouveau capteur de présence) se fait une seule fois dans le script de notification et sera ainsi mis à jour automatiquement dans toutes les applications qui l'utilisent.

Quelques grands choix d'architecture

La manière d'écrire votre code ou certains choix de fonctionnalités peuvent avoir un impact :

• sur le code lui-même et sa lisibilité
• sur la façon dont vos automatisations se déroulent et leur efficacité

Dans ce chapitre, nous allons entrer plus en détail dans certaines questions plus avancées ou même certains débats quasi philosophiques. Alors accrochez-vous!

Vaut il mieux "Plusieurs automatisations simples" ou "Une seule automatisation complexe" ?

Question digne du bac de Philo avec option HA. Vous avez 4 heures !

Il est possible, dans une automatisation, de nommer les déclencheurs (id). Ceci permet ensuite d'utiliser la condition "déclenché par" à plusieurs endroits :

• dans les conditions, pour les adapter en fonction du déclencheur
• dans les actions, pour l'utiliser dans des blocs "choisir" et ainsi adapter les actions à effectuer en fonction du déclencheur

Ceci permet alors de regrouper ce qu'on aurait fait à l'aide de plusieurs automatisations simples, au sein d'une seule automatisation un peu plus complexe.

Ce choix est très personnel, je vous propose de vous montrer comment faire, ensuite, vous déciderez seul de vos préférences.

Un exemple, en reprenant l'automatisation simple du premier article:

On peut au choix :

• Définir une deuxième automatisation pour l'extinction
• Ajouter un déclencheur pour l'extinction et tester les id des déclencheurs pour choisir quoi faire, avec la condition "déclenché par", dans les conditions et dans les actions :
  • Il faut alors nommer les déclencheurs en leur attribuant une id:

• On peut alors définir les id des deux déclencheurs :

• Puis utiliser la condition "[ID] Déclenché par" dans les conditions ou dans les actions pour définir des comportements qui peuvent être différents suivant les déclencheurs :

• L'automatisation finale, on a modifié les conditions et les actions avec des conditions "déclenché par" :

• Le code complet sera le suivant :

alias: Lumière - Gestion auto Ampoule
description: >-
  Allumage automatique de "ampoule" sur detection par "détecteur", uniquement la
  nuit. (id:Présence)

  Extinction automatique de l'ampoule en fin de detection (id:Absence)
triggers:
  - trigger: state
    entity_id:
      - input_boolean.detecteur
    to:
      - "on"
    id: Présence
  - trigger: state
    entity_id:
      - input_boolean.detecteur
    to:
      - "off"
    id: Absence
conditions:
  - condition: or
    conditions:
      - condition: state
        entity_id: sun.sun
        state:
          - below_horizon
      - condition: trigger
        id:
          - Absence
actions:
  - choose:
      - conditions:
          - condition: trigger
            id:
              - Présence
        sequence:
          - action: light.turn_on
            metadata: {}
            target:
              entity_id: light.ampoule
            data: {}
      - conditions:
          - condition: trigger
            id:
              - Absence
        sequence:
          - action: light.turn_off
            metadata: {}
            target:
              entity_id: light.ampoule
            data: {}
mode: single

Il y a des avantages à cette solution :

• Un aspect tout-en-un de l'automatisation (ici allumage et extinction sont dans le même code) => un seul fichier.
• Dans certains cas, on peut utiliser les mêmes parties de code pour plusieurs déclencheurs, et ainsi écrire un peu moins de code.
• En cas de modification ou de duplication, un seul fichier à ouvrir et modifier, moins de risque d'oubli.
• Dans certain cas l'id de déclenchement peut vous intéresser directement dans vos actions, par exemple utiliser le modèle {{ trigger.id }} directement dans une notification pour donner en clair le nom du déclencheur (par exemple qui est rentré à la maison, quelle erreur ajouter au message de notification)

Mais il y a aussi des inconvénients :

• Une structure de l'automatisation moins facile à lire, car les logiques liées aux différents déclencheurs sont entremêlées => pensez à bien commenter vos automatisations
• Des codes plus longs par rapport à des automatisations simples

Maîtriser le temps : action "délai" ou entité "minuteur"

Entre le deuxième article et celui-ci, nous avons vu deux façons de gérer le temps dans la séquence d'actions :

• le bloc d'action "attendre que le temps passe (délai)" (delay):

• l'Entrée "Minuteur" (timer) dans cet article parmi les entrées (helper).

Ces deux concepts vont tous les deux permettre d'attendre un certain temps avant de poursuivre la séquence d'action. Mais quelles sont leurs différences, et dans quel cas vaut-il mieux utiliser l'un que l'autre ?

Le bloc "délai" stoppe momentanément l'exécution de la séquence d'action, avant de la reprendre à la fin de la temporisation. En cas de redémarrage de Home Assistant, toutes les automatisations en cours d'exécution sont perdues. Si une attente de ce type est en cours, l'automatisation étant arrêtée, les actions suivantes ne seront jamais effectuées.

Le minuteur lui (si on a coché la case "restaurer l'état et l'heure au démarrage de Home Assistant") offre une sécurité supplémentaire. Au redémarrage de Home assistant, l'état du minuteur et son heure de fin seront restaurés, il y aura là deux possibilités :

• soit le redémarrage a lieu avant l'heure de fin du minuteur, et celui-ci reprend alors comme si de rien n'était, les actions prévues en fin de minuteur seront effectuées après le délai prévu comme si rien ne s'était passé.
• soit le redémarrage a lieu après l'heure de fin du minuteur, et home assistant va alors générer l'évènement "fin du minuteur" au moment du redémarrage. Le minuteur aura alors duré plus longtemps que prévu, mais se terminera tout de même, permettant d'effectuer les actions prévues au moment où HA redémarre.

Il suffit alors de créer un déclencheur "évènement" (event) sur cet évènement "fin de minuteur" (timer.finished). Soit dans une autre automatisation, soit dans la même automatisation avec des id de déclencheurs (choix personnel, nous ne referons pas le débat du paragraphe précédent).

À noter, en plus de permettre de gérer le temps, le minuteur dispose d'un état (on ou off) permettant de savoir s'il est en cours ou non, on pourra ainsi tester cet état, ou afficher les informations du minuteur sur un dashboard (durée restante, heure de fin, état).

Un exemple pratique :

Pour illustrer les gains du minuteur par rapport au délai : l'utilisation d'un minuteur pour gérer un éclairage.

Avec trois automatisations (ou une seule combinée plus complexe si vous préférez) on peut gérer un éclairage à la fois en mode manuel et en mode automatique : en utilisant l'état du minuteur pour savoir si l'allumage a été automatique ou non:

• allumage automatique sur détection (lors d'une détection de mouvement, si la lampe est éteinte et le minuteur non actif, on lance un minuteur et on allume la lampe, sinon, si le minuteur est actif, on le relance, et sinon on ne fait rien), donc le minuteur n'est actif que si la lampe n'est pas allumée manuellement au départ.
• extinction automatique à la fin du minuteur (lorsque l'évènement de fin de minuteur est reçu, on éteint la lampe), donc pas d'extinction si la lampe a été allumée manuellement.
• gestion du minuteur : lorsqu'on éteint la lampe manuellement, il faut bien penser à stopper le minuteur s'il est actif (ce qui n'envoie pas l'évènement de fin de minuteur).

Le minuteur se comporte donc à la fois comme un délai (gestion du temps) et comme un booléen qui trace l'allumage en mode automatique.

# automatisation d'allumage

alias: Lumières - allumage automatique
description: >-
  lorsqu'un mouvement est détecté entre 20h30 et 7h15
  l'ampoule s'allume et lance le timer
triggers:
  - trigger: state
    entity_id:
      - binary_sensor.presence
    to:
      - "on"
conditions:
  - condition: time
    after: "19:00:00"
    before: "07:15:00"
actions:
  - if:
      - condition: state
        entity_id: light.ampoule
        state: "off"
    then:
      - action: timer.start
        data: {}
        target:
          entity_id: timer.alumage_ampoule
        
      - action: light.turn_on
        data: {}
        target:
          entity_id: light.ampoule
    else: []
  - if:
      - condition: state
        entity_id: timer.alumage_ampoule
        state: active
    then:
      - action: timer.start
        data: {}
        target:
          entity_id: timer.alumage_ampoule
mode: single


# automatisation d'extinction

alias: Lumières - extinction auto timer
description: >-
  extinction auto  de l'ampoule à la fin du timer si inoccupé sinon relance du
  timer
triggers:
  - event_type: timer.finished
    event_data:
      entity_id: timer.alumage_ampoule
    trigger: event
conditions: []
actions:
  - if:
      - condition: state
        entity_id: binary_sensor.presence
        state: "on"
    then:
      - data: {}
        target:
          entity_id: timer.alumage_ampoule
        action: timer.start
    else:
      - action: light.turn_off
        metadata: {}
        data: {}
        target:
          entity_id: light.ampoule
mode: single


# automatisation de gestion du timer

alias: Lumières - gestion timer
description: annule le timer quand la lumière devient off
triggers:
  - trigger: state
    entity_id:
      - light.ampoule
    to:
      - "off"
conditions: []
actions:
  - action: timer.cancel
    data: {}
    target:
      entity_id: timer.alumage_ampoule
mode: restart

Maîtriser le mode d'exécution pour éviter les erreurs

Que se passe-t-il si plusieurs déclenchements se produisent de façon rapprochée et que l'automatisation n'est pas terminée? S'arrête-t-elle et redémarre-t-elle? Termine t'elle sa tache puis recommence ? Est-ce qu'une autre automatisation se lance en parallèle ? En fait, c'est vous qui choisissez !

Le mode d'exécution (mode) définit la façon de gérer ce type de conflit, on peut le régler dans l'interface ou en YAML. Il suffit de cliquer sur le menu en haut à droite puis sur modifier le mode :

Vous aurez alors le choix entre quatre modes :

• Le mode Unique (single) : le mode par défaut si vous ne sélectionnez rien.
• Le mode Redémarrage (restart)
• Le mode File d'attente (queued)
• Le mode parallèle (parallel)

Dans la doc officielle en anglais, un petit schéma bien pratique montre le fonctionnement de ces quatre modes si un second déclencheur (second call dans le schéma) se produit alors que l'automatisation n'a pas terminé sa séquence d'action :

Gérer les erreurs si elles se produisent

Tout d'abord en utilisant les traces de débug vues dans le premier article. Par défaut Home Assistant conserve les 5 dernières traces de chaque automatisation.

Si on ajoute a la fin de l'automatisation le code yaml suivant, on peut définir le nombre de traces conservées (ici 50) :

trace:
  stored_traces: 50

Ceci vous permettra sans doute de trouver une trace de débug présentant l'erreur qui vous dérange si celle-ci n'est pas systématique.

Et si vous vous rendez compte qu'un élément (déclencheur, condition ou action) pose un problème, vous pouvez temporairement le désactiver (enabled: false) ou le réactiver comme bon vous semble en YAML comme avec l'interface.

Vous pouvez aussi ajouter dans le code de l'action problématique continue_on_error: true pour que l'action continue tout de même. Ceci ne marchera pas dans tous les cas d'erreurs, mais dans certains cas vous permettra de continuer vos automatisations malgré une intégration dont l'action présente souvent des erreurs. Depuis la version 2026.3, cette possibilité est disponible dans l'interface aussi :

Les étapes sont identifiées par une petite icône dans l'interface :

Pour aller encore plus loin, vous pouvez séparer vos actions (dans des scripts) de vos automatisations. Ainsi si une action est en erreur, l'automatisation continuera tout de même. Pratique pour des automatisations vraiment critiques.

Il faut ensuite sécuriser le lancement du script comme ceci :

- action: script.turn_on
  metadata: {}
  target:
    entity_id: script.test_plantage
  data: {}

Et non comme ceci :

- action: script.test_plantage
  metadata: {}
  data: {}

Dans le premier cas, l'automatisation lance le script et continue ensuite ses actions en parallèle, alors que dans le second, elle s’arrête et attend la fin du script pour pouvoir continuer la séquence d'actions. Si le script présente une erreur, dans le premier cas l'automatisation continue, dans le second, elle s'arrête.

Les Blueprints pour simplifier votre code et le partager facilement

Ce sont des modèles d'automatisation ou de script prêts à l'emploi et partageables. Vous pouvez grâce à eux définir plus facilement une automatisation ou un script. Si l'on reprend notre exemple désormais culte de l'automatisation qui gère une ampoule en fonction d'un détecteur de mouvement.

Un blueprint vous permet de définir tout le cadre général de l'automatisation, puis de créer une automatisation simplement en spécifiant quelles entités utiliser pour le détecteur et l'ampoule. En bonus, vous pouvez créer autant d'automatisations que nécessaires à partir du même blueprint (si vous avez plusieurs détecteurs pilotant plusieurs ampoules).

Enfin comme les automatisations créées sont issues du même blueprint, si vous mettez à jour ce dernier, toutes les automatisations seront mises à jour aussi.

Utiliser un blueprint :

Vous avez peut-être généré un blueprint. Bravo ! Mais le cas le plus courant sera souvent d'en récupérer un de la communauté. Il suffit alors, dans l'onglet "blueprint" de cliquer sur "+ importer un blueprint"

Renseignez l'adresse que vous aurez trouvée sur le net.

Par exemple, cliquez ici: blueprint télécommande LM

Après avoir cliqué sur aperçu, on obtient :

Si on clique sur importer, il devient disponible dans notre onglet Blueprint:

En cliquant dessus, on ouvre l'interface :

Il n'y a plus qu'à remplir les champs, puis cliquer sur enregistrer pour générer une automatisation issue de ce blueprint.

On clique sur enregistrer, et comme pour toute automatisation toute neuve, il faut lui donner un nom :

Et voilà une automatisation toute neuve en quelques clics. Facile à réaliser, quelle que soit la complexité de l'automatisation, le blueprint ne vous demande que vos paramètres, le reste est "caché".

Vous voulez voir comment c'est fait ? Alors dans l'onglet Blueprint, sélectionnez celui que vous voulez, puis dans le menu en haut à droite, cliquez sur "prendre le contrôle":

et voilà, ça ressemble fichtrement à une automatisation bien classique non ?

Par contre, si vous prenez le contrôle, cela redevient une automatisation classique, le lien avec le blueprint est coupé, c'est vous et vous seul qui avez la main.

Créer ses propres blueprints pour se faciliter la vie ou les partager

Si vous souhaitez transformer une automatisation réussie en blueprint pour la réutiliser ou la partager, c'est possible.

Cela se fait en mode YAML, par exemple en partant de votre automatisation, et en y ajoutant des champs spécifiques au blueprint, en particulier en déclarant les champs variables (input) pour remplacer les entités spécifiques de votre automatisation par des variables qui seront renseignées plus tard lors de l'utilisation du blueprint. (Un peu de la même manière qu'on renseigne des champs dans un script...)

On arrive là dans un mode suffisamment avancé pour que vous trouviez tous seuls les tutos et les ressources pour faire tout cela. Par exemple la doc officielle propose un tutoriel et une vidéo (en anglais) qui détaille toutes les étapes pas à pas : https://www.home-assistant.io/docs/blueprint/tutorial/

Ne soyez pas intimidés par des outils "avancés"

Utilisez SPOOK !

Dans le deuxième article, je vous parlais un peu des actions offertes par spook (disponible dans HACS, le store communautaire), car elles 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. Mais ce n'est pas tout, car Spook ajoute aussi son lot de capteurs et d'entrées bien pratiques.

Une des options les plus intéressantes offerte par spook, c'est qu'il flotte en permanence tel un gentil fantôme dans votre Home Assistant, surveillant tout, en particulier vos automatisations, scripts, scènes, mais aussi vos dashboards. S'il y trouve la moindre référence inconnue à une entité, un appareil, une action, une zone, etc... Il vous créera une note de réparation avec la description du problème.

Un exemple, vous changez de téléphone et supprimez donc l'ancien appareil dans Home Assistant, Spook vous indiquera tous les endroits où cet appareil (devenu inconnu) est utilisé, vous permettant ainsi de le remplacer par le nouveau absolument partout.

Et s'il faut finir de vous convaincre, Spook est créé par Frenck, un des développeurs principaux de Home Assistant.

Utilisez le YAML !

Dans toute cette série d'articles, je vous ai montré qu'il est possible de tout faire sans écrire une seule ligne de code ou presque.

Mais il faut tout de même reconnaitre que savoir lire et écrire un minimum de YAML vous permettra d'être encore plus efficace.

Alors ne soyez pas timides, observez le code généré par l'interface, lisez ce qui est partagé sur le forum, cherchez des ressources pour comprendre (en particulier la documentation officielle).

Et rapidement, certaines structures vous paraitrons presque naturelles, et l'indentation du YAML n'aura plus de secret pour vous...

Conclusion : les automatisations n'ont plus de secret pour vous désormais

Vous avez maintenant toutes les clés pour créer, fiabiliser et maintenir vos propres automatisations, même les plus complexes. De la gestion simple de l'éclairage aux scénarios multi-étapes, vous êtes prêt à exploiter toute la puissance de Home Assistant, efficacement et durablement.

N'oubliez pas les règles d'or : testez, débuggez et documentez votre travail.

L'apprentissage passe par l'expérimentation, alors lancez-vous !

Pour aller plus loin, lisez la documentation officielle (en anglais certes, mais des outils de traduction existent si vous êtes allergiques), et n'ayez pas peur du YAML, certaines options (de moins en moins) ne sont pas disponibles dans l'interface graphique.

N'hésitez pas à partager sur le forum vos exemples d'automatisations, voir même à générer des blueprints pour la communauté !

Si vous pensez qu'il manque des aspects à cette série d'articles, le forum est là pour faire part de vos suggestions, et pourquoi ne pas franchir le pas et devenir rédacteurs...