Scénario Studio ne pilote pas la maison : il écrit des automatisations dans Home Assistant, qui les exécute. Cet article détaille cette frontière — comment l'application dialogue avec Home Assistant, ce qu'elle y écrit exactement, et les garde-fous qui l'empêchent d'abîmer une installation existante.
Trois appels de service, et pas un de plus
Le client Home Assistant de l'application n'émet que trois appels, tous du domaine automation : activer, désactiver, recharger. Aucun appel du domaine light ou cover n'en part. Les services d'ouverture et de fermeture de volet n'existent qu'à l'intérieur du YAML produit, exécuté par Home Assistant le moment venu.
C'est une propriété vérifiable, et c'est ce qui garantit qu'un scénario déployé continue de tourner alors que l'application est éteinte.
Deux API, parce qu'une seule ne suffit pas
- L'API REST donne les entités et leurs états : c'est la synchronisation de base.
- L'API WebSocket donne les registres — pièces et appareils. Ces informations ne sont accessibles que là, et sans elles un volet ne pourrait pas être rattaché à sa pièce.
Autre choix de synchronisation : rien n'est jamais supprimé du miroir local. Une entité disparue de Home Assistant est marquée indisponible. Une ligne de planning qui pointe dessus reste donc visible, avec son problème affiché — au lieu de s'évaporer silencieusement et d'emporter avec elle une action de la journée.
Le miroir local : chaque libellé métier pointe vers une entité, avec sa nature, sa pièce et sa disponibilité. Les identifiants techniques restent visibles, mais on ne les manipule jamais dans un planning.
Le garde-fou : ne jamais toucher ce qui ne vient pas de nous
Tout ce que l'application écrit porte une double marque : un préfixe dans l'identifiant technique, et un marqueur dans le libellé lisible. Un composant dédié contrôle cette marque avant chaque écriture et avant chaque suppression. Une tentative de suppression visant un identifiant non marqué lève une erreur — et un test le démontre plutôt que de le promettre.
Une installation domotique contient des automatisations écrites à la main, parfois depuis des années. Un outil qui écrit dedans doit prouver qu'il ne peut pas les détruire, pas simplement affirmer qu'il fait attention.
Ce que produit le générateur : une étape horaire
Une étape à 7 h 15, sur le jour-type « semaine » d'une période allant du 15 au 29 août, donne ceci :
- id: scnstudio_1fee426f50dc5306ab0846cfe26d179a
alias: '[SCN] Vacances août / SEMAINE / 07:15 / matin'
description: Généré par Scénario Studio — ne pas éditer à la main
mode: single
trigger:
- platform: time
at: '07:15:00'
condition:
- condition: template
value_template: '{{ ''2026-08-15'' <= now().strftime(''%Y-%m-%d'') <= ''2026-08-29'' }}'
- condition: time
weekday: [mon, tue, wed, thu, fri]
action:
- delay:
seconds: '{{ range(0, 420) | random }}'
- service: cover.open_cover
target:
entity_id: cover.volet_chambre
Trois détails de ce fragment ont demandé plus de réflexion qu'il n'y paraît.
- La borne de dates est une comparaison de chaînes. Au format ISO, l'ordre alphabétique coïncide avec l'ordre chronologique : on évite ainsi toute arithmétique de dates dans un gabarit exécuté par Home Assistant, source classique d'erreurs qui ne se voient pas.
- Les heures sont écrites entre apostrophes. Dans la version de YAML utilisée, 18:45:00 non protégé se lit comme un nombre en base soixante. Un représenteur maison force le bon format à l'écriture.
- L'aléa est borné par étape. Chaque automatisation tire son propre retard, dans une borne calculée pour que l'écart minimal entre deux étapes reste garanti même dans le pire tirage. La garantie est mathématique, pas espérée — et chaque automatisation reste autonome, sans coordination entre elles.
Côté interface, une routine s'énonce en une phrase. Le YAML ci-dessous est ce que le générateur en tire, déclencheurs compris.
Ce que produit le générateur : une routine de contrôle
- id: scnstudio_e486e09014a55f878693eb6273e24ded
alias: '[SCN] Vacances août / contrôle / Soleil du matin sur la chambre'
mode: single
trigger:
- platform: numeric_state
entity_id: sensor.temp_exterieure
above: 25
for: '00:02:00'
- platform: numeric_state
entity_id: sensor.lux_chambre
above: 500
for: '00:02:00'
- platform: time
at: '06:00:00'
- platform: homeassistant
event: start
condition:
- condition: time
after: '06:00:00'
before: '20:00:00'
- condition: numeric_state
entity_id: sensor.temp_exterieure
above: 25
- condition: numeric_state
entity_id: sensor.lux_chambre
above: 500
action:
- service: cover.close_cover
target:
entity_id: cover.volet_chambre
Trois familles de déclencheurs, chacune bouchant un trou que les autres laissent :
- le franchissement de seuil couvre le cas normal — la luminosité monte ;
- l'ouverture de la fenêtre horaire couvre le seuil déjà franchi avant l'heure : à 6 h, le soleil peut déjà taper, et aucun franchissement ne se produira plus ;
- le démarrage de Home Assistant couvre le redémarrage en pleine journée.
Ce sont des événements, jamais une surveillance périodique. Une routine agit une fois, là où un contrôle toutes les cinq minutes ferait cliqueter les volets à chaque nuage. Le délai de confirmation associé à chaque seuil joue le même rôle : il évite l'aller-retour sur une variation passagère.
Enfin, un capteur indisponible fait échouer sa condition, donc la routine ne se déclenche pas : mieux vaut un volet immobile qu'un volet piloté sur une mesure absente. Le validateur classe ce cas en erreur et bloque le déploiement — une protection hors service sans qu'on le sache est pire qu'une protection absente.
Pourquoi jamais de pilotage par position
Les volets concernés ne sont pas calibrés, un défaut connu de leurs modules radio : leur demander une position donnerait un résultat imprévisible. Le pilotage par pourcentage est donc absent de tout le projet — pas seulement déconseillé, mais impossible à exprimer dans le modèle de données. Une fermeture partielle devient une fermeture, une attente, puis un arrêt.
Déployer, retirer, et retrouver les résidus
Un déploiement se déroule toujours dans le même ordre : retirer les automatisations des autres périodes de l'application — il n'y en a jamais deux actives —, écrire les nouvelles, puis demander à Home Assistant de recharger sa configuration.
Le retrait fait l'inverse et ne laisse rien. Pour les cas où le déroulement a été interrompu — coupure, base restaurée à un état antérieur — un écran liste les automatisations marquées présentes dans Home Assistant mais absentes de la base, et permet de les supprimer. Là encore, c'est la marque de fabrique qui rend l'opération sûre.
Éprouver un déploiement sans toucher aux volets
L'application embarque une fausse instance Home Assistant complète, qui répond en REST et en WebSocket. Un mode développement capture d'abord les équipements réels — en lecture seule — puis débranche la maison : le simulateur prend le relais et se branche comme un simple transport, si bien que le client ne sait pas qu'il ne parle pas à une vraie installation.
On peut ainsi dérouler un déploiement complet, avec son propre matériel et ses propres pièces, sans qu'un seul volet ne bouge. Pour un outil qui agit sur le monde physique, c'est la différence entre tester et espérer.
Ce que Home Assistant ne fera pas à votre place
Un point à connaître : Home Assistant n'arbitre pas entre deux automatisations contradictoires — la dernière déclenchée l'emporte. L'outil signale les contradictions qu'il sait démontrer, mais il ne peut pas les supprimer. C'est une limite du terrain, pas de l'implémentation, et mieux vaut l'avoir en tête au moment de dessiner deux routines qui visent le même volet.