Onze volets motorisés, une automation qui recalcule leurs positions toutes les 5 minutes, et un mode sieste qui verrouille une chambre en un tap. Retour d’expérience sur une automatisation qui a l’air simple sur le papier et qui m’a pris dix-neuf versions pour devenir fiable.
Le problème du volet qui n’écoute personne
Un volet roulant motorisé, c’est binaire dans la tête du fabricant : ouvert, fermé, ou une position figée qu’on choisit une fois pour toutes. Sauf que le soleil, lui, bouge. Une baie orientée plein ouest qui encaisse un soleil rasant à 18h n’a pas besoin de la même protection qu’à midi. Sans automatisation, ça veut dire soit vivre volets fermés en permanence (adieu la lumière naturelle), soit sortir l’application du fabricant plusieurs fois par jour. Aucune des deux options ne me convenait, et je voulais en plus pouvoir bloquer une chambre entière quand quelqu’un y fait la sieste, sans que le système ne vienne rouvrir le volet par-dessus.
Le contexte : matériel imposé, logique à construire
Le point de départ, c’est du matériel grand public : une passerelle Somfy Tahoma (protocole Overkiz) qui pilote onze volets roulants motorisés. Tahoma gère déjà l’ouverture du matin et la fermeture du soir nativement, donc pas question de dupliquer cette logique côté Home Assistant, ça créerait des conflits inutiles. Ce qui manquait, c’était la couche intelligente entre les deux : la protection contre le soleil pendant la journée.
Contrainte matérielle importante : la passerelle Overkiz n’accepte qu’une commande à la fois, avec un délai minimum entre chaque ordre. Impossible d’envoyer une position à un groupe de volets d’un coup, il faut itérer volet par volet avec une pause. Ça a structuré toute l’architecture des scripts.
Chaque volet physique expose par ailleurs deux entités : une en vitesse normale et une en vitesse lente. Tous les scripts et automations utilisent systématiquement la version lente, plus douce mécaniquement et plus fiable pour détecter les transitions d’état.
L’implémentation : delta angulaire et grille de décision
Le cœur du système, c’est un calcul d’angle entre la position du soleil et l’orientation de chaque façade. Pour une façade orientée à 250° par exemple, on calcule l’écart avec l’azimut du soleil au moment T :
template:
- sensor:
- name: "Cible position facade ouest"
unique_id: volets_ouest_position_cible_soleil
state: >
{% set azimuth = state_attr('sun.sun', 'azimuth') | float(0) %}
{% set orientation = 250 %}
{% set delta = ((azimuth - orientation + 180) % 360 - 180) | abs %}
{% set elevation = state_attr('sun.sun', 'elevation') | float(0) %}
{% if delta < 20 and elevation > 25 %}
35
{% elif delta < 35 and elevation > 20 %}
45
{% elif delta < 65 and elevation > 15 %}
70
{% else %}
100
{% endif %}
attributes:
facade_orientation: 250
angle_soleil: >
{{ ((state_attr('sun.sun','azimuth')|float(0) - 250 + 180) % 360 - 180) | abs }}
Chaque façade a sa propre grille de seuils, avec une règle simple : plus l’exposition est tardive dans la journée (façade ouest en fin d’après-midi), plus le soleil est rasant et pénétrant, donc plus les seuils de déclenchement sont bas. Une façade sud se protège dès que le soleil tape en face à midi ; une façade ouest doit se protéger même avec un soleil déjà bas sur l’horizon.
Le script d’application respecte la contrainte de la passerelle en itérant volet par volet avec un délai fixe :
script:
volets_facade_ouest_45:
sequence:
- repeat:
for_each:
- cover.baie_ouest_1_low_speed
- cover.baie_ouest_2_low_speed
- cover.panoramique_ouest_low_speed
sequence:
- service: cover.set_cover_position
target:
entity_id: "{{ repeat.item }}"
data:
position: 45
- delay:
milliseconds: 600
Ne cible jamais un groupe de covers directement avec set_cover_position si ta passerelle n’accepte qu’une commande à la fois : ça envoie tout d’un coup et ça sature la gateway. Itère toujours volet par volet avec un délai, même si c’est trois lignes de YAML en plus.
Pour le mode sieste, le principe est différent : plutôt que d’ajouter des conditions dans chaque script, j’ai créé un input_boolean qui bloque une entité précise à la source, avec un cover proxy qui devient indisponible tant que le mode est actif. Résultat : même les boutons du dashboard deviennent grisés automatiquement, sans logique supplémentaire à maintenir côté interface.
Les pièges rencontrés (la partie qui m’a coûté le plus de temps)
Le vrai défi de ce projet, ce n’est pas le calcul de position, c’est de distinguer un mouvement provoqué par l’automation d’un mouvement provoqué par une personne. Si l’auto ne sait pas faire cette différence, elle finit soit par ignorer des vraies actions manuelles, soit pire, par se bloquer elle-même en croyant qu’on vient de la contredire.
J’ai d’abord tenté de détecter les overrides avec une simple fenêtre temporelle après chaque commande de l’auto : si un volet change d’état dans les secondes qui suivent, c’est l’auto elle-même. Ça a tenu quelques semaines, jusqu’au jour où l’auto a rouvert plusieurs volets d’un coup après un retour de mode absent, avec un mouvement mécanique de 45 à 50 secondes, largement au-dessus de la fenêtre de détection. Résultat : l’automation a marqué ses propres volets comme « override manuel » et les a exclus du système, en plein soleil, pour le reste de l’après-midi.
La correction a été de changer complètement d’approche : plutôt qu’une fenêtre de temps globale, l’auto inscrit désormais chaque volet qu’elle vient de commander dans une liste dédiée, vidée à chaque nouveau cycle. La détection d’override ne se déclenche que si le volet concerné n’y figure pas. Une reconnaissance par entité plutôt que par horloge, beaucoup plus robuste.
Le second incident, plus embêtant, concernait justement la chambre protégée par le mode sieste. Un soir, un mécanisme de « reprise de contrôle » (retour à la maison détecté par géolocalisation) a déclenché un recalcul immédiat de toutes les positions, y compris pour le volet de la chambre où quelqu’un dormait, alors que le mode sieste n’avait pas été activé manuellement à ce moment précis. Le volet s’est rouvert en pleine soirée. La leçon : un toggle manuel seul n’est pas une protection suffisante s’il dépend de la mémoire de quelqu’un pour être activé. J’ai ajouté une fenêtre horaire par défaut (grosso modo journée uniquement) qui bloque ce volet spécifique en dehors des heures raisonnables, indépendamment du mode sieste. Le toggle manuel reste utile en journée pour une sieste ponctuelle, mais le filet de sécurité horaire couvre les cas où on oublie de l’activer.
Depuis la 2026.7 : ce qui ne demande plus de YAML
La mise à jour Home Assistant 2026.7 a changé la manière de construire une automatisation dans l’éditeur graphique. Les triggers et conditions orientés intention (mouvement détecté, batterie faible, seuil de température, élévation du soleil) sont désormais le comportement par défaut, et surtout une automatisation peut maintenant cibler une zone entière plutôt qu’une entité précise. Concrètement, une protection soleil simple du type « quand le soleil tape sur la façade sud, ferme les volets de cette zone à 50 % » peut aujourd’hui se construire entièrement dans l’éditeur, sans écrire une ligne de YAML : tu choisis le trigger lié à l’élévation du soleil, tu cibles la zone concernée, et l’éditeur gère lui-même les états unknown ou unavailable qui posaient problème avant. Si un capteur de cette zone est remplacé ou ajouté plus tard, l’automatisation continue de fonctionner sans rien retoucher.
Pour ce qui est décrit dans cet article, en revanche, le YAML garde tout son intérêt. Les paliers de position selon l’heure et l’élévation du soleil, le mode sieste qui verrouille un volet précis, les gardes horaires multiples et la distinction entre override manuel et mouvement automatique sont des enchaînements de conditions que l’éditeur graphique ne couvre pas encore aussi bien. Le conseil pratique reste simple : démarre en interface graphique pour les cas simples et ponctuels, et ne passe en YAML que lorsque la logique devient réellement conditionnelle, pas par réflexe.
Bilan : ce qui reste à améliorer
Le système tient la route aujourd’hui, mais il reste artisanal sur un point : je n’ai aucun capteur de luminosité extérieure. Toute la logique repose sur l’azimut, l’élévation du soleil et la météo prévisionnelle, ce qui fonctionne bien par ciel dégagé mais reste approximatif un jour de nuages changeants. Un capteur de rayonnement solaire dédié simplifierait sans doute une bonne partie de la grille de seuils actuelle. Je pense aussi à terme automatiser la détection « volets encore chauds » après une canicule avec un vrai capteur de température de surface plutôt qu’une estimation basée sur la météo extérieure, l’estimation actuelle fonctionne mais reste un proxy imparfait.
FAQ
Pourquoi ne pas tout gérer directement avec la passerelle du fabricant ?
La passerelle gère bien l’horaire fixe (matin/soir), mais pas la logique conditionnelle (soleil + météo + température). Home Assistant vient compléter, pas remplacer, ce que fait déjà bien le matériel existant.
Comment l’automation distingue-t-elle une action manuelle d’un mouvement automatique ?
Chaque volet commandé par l’auto est inscrit dans une liste temporaire à chaque cycle. Un changement d’état sur un volet absent de cette liste est considéré comme manuel et exclut ce volet des cycles suivants.
Le mode sieste bloque-t-il tout le système de volets ?
Non, il ne bloque que l’entité ciblée. Les autres volets continuent d’être gérés normalement par l’automation de protection solaire.
Que se passe-t-il si un volet est fermé manuellement pendant la journée ?
L’automation considère qu’un volet en dessous d’un certain seuil de fermeture a été fermé volontairement et ne le rouvre jamais elle-même, même si la logique de protection solaire recalcule une position plus ouverte.
Stack utilisée
- Home Assistant (automations, scripts, template sensors, packages YAML)
- Passerelle Somfy Tahoma (protocole Overkiz)
- Volets roulants motorisés IO Homecontrol
- Intégration Sun (azimut, élévation)
- Intégration météo (prévisions et conditions)
- Sonde de température extérieure physique
- Helpers input_boolean / input_text pour les toggles et le stockage des overrides
