Comment j'ai basculé mon automatisation de volets roulants 🪟 de Jeedom vers Home Assistant

En bref

Prérequis	Home Assistant opérationnel, volets roulants pilotables depuis HA
Résultat	Automatisation complète : ouverture/fermeture solaire, modes multiples, gestion absence, bascule jour/nuit
Ressources	Vidéo Jeedom volets roulants · Intégration Sun HA

---

Le guide complet

Contexte : une migration, pas une traduction

Quand on migre de Jeedom vers Home Assistant, il ne faut pas chercher à reproduire les scénarios Jeedom à l’identique. Le concept de scénario (Jeedom) et le concept d’automatisation (Home Assistant) sont différents dans leur structure et leur logique. C’est l’occasion de repenser ce qu’on a fait, parfois avec 10 ans de recul.

Mon automatisation de volets roulants date de mes débuts en domotique. Je l’ai revisitée et refaite plus proprement dans Home Assistant.

Prérequis : piloter les volets depuis HA

Avant d’automatiser, il faut pouvoir commander les volets. Dans mon cas, j’utilise un GCE IPX 800 V4 avec des relais soudés sur les boutons haut/bas d’un interrupteur centralisé Bubendorf. C’est lui qui simule l’appui sur les boutons physiques.

Votre installation sera différente — peut-être une commande centralisée, un module Z-Wave sur chaque volet, ou autre. L’essentiel : avoir des entités Home Assistant qui ouvrent et ferment vos volets.

Étape 1 : créer l’entité mode (input_select)

Plutôt que de multiplier les automatisations, j’utilise une seule automatisation pilotée par un input_select — une liste déroulante qui définit le mode courant.

Mes modes :

• Ouverture — ouverture automatique au lever du soleil uniquement
• Fermeture — fermeture automatique au coucher uniquement
• Fermeture si absent — fermeture automatique uniquement si personne n’est dans le logement
• Ouverture et fermeture — les deux automatisés
• Ouverture et fermeture — vacances — idem mais ouverture à heure fixe (9h15) au lieu du lever solaire
• Désactivé — aucune automatisation

Pour créer l’input_select : Paramètres → Appareils et services → Entrées → Créer une entrée → Liste déroulante. Donnez-lui un nom, une icône, et listez vos options.

Le nommage des options est important : l’automatisation va tester si le mot “ouverture” ou “fermeture” est contenu dans la valeur courante. Restez cohérent dans la casse.

Étape 2 : créer les entités soleil ajustées

L’intégration Sun (Soleil) de Home Assistant donne les heures brutes de lever et coucher. Je veux les décaler : +15 min pour le lever, +10 min pour le coucher.

Plutôt que de coder ces décalages directement dans l’automatisation, je crée deux entités template :

• sensor.sun_next_rising_adjusted — prochain lever ajusté (+15 min)
• sensor.sun_next_setting_adjusted — prochain coucher ajusté (+10 min)

Paramètres → Appareils et services → Entrées → Créer → Template → Capteur

Formule pour le lever ajusté :

{{ (as_datetime(states('sensor.sun_next_rising')) + timedelta(minutes=15)) | as_local }}

Même chose pour le coucher avec timedelta(minutes=10).

L’avantage : ces valeurs sont visibles dans le tableau de bord, modifiables à un seul endroit, et réutilisables dans d’autres automatisations.

Étape 3 : l’automatisation principale

Paramètres → Automatisations → Créer une automatisation

Les déclencheurs

Trois déclencheurs, tous nommés (l’ID de déclenchement est important — il servira dans les conditions) :

1. ID “lever” — Type : Heure et lieu → Heure → sensor.sun_next_rising_adjusted
2. ID “coucher” — Type : Heure et lieu → Heure → sensor.sun_next_setting_adjusted
3. ID “lever_9h” — Type : Heure et lieu → Heure fixe → 09:15 (mode vacances)

Pour ajouter un ID à un déclencheur : dans l’éditeur de code du déclencheur, ajoutez id: lever. Pas accessible depuis l’interface graphique standard.

La condition globale

Une seule condition additionnelle : le mode ne doit pas être “Désactivé”. Inutile de déclencher la logique si on est en mode manuel.

Le bloc choose (3 options)

Option 1 — Ouverture

Conditions :

• Le mot “ouverture” est contenu dans l’état de l’input_select
• ET le déclencheur est “lever” ET le mode contient “ouverture fermeture vacances” → NON (pas en mode vacances)
• OU le déclencheur est “lever_9h” ET le mode contient “vacances”

Action : activer les relais d’ouverture + notification de confirmation.

Option 2 — Fermeture standard

Conditions :

• Le déclencheur est “coucher”
• ET le mot “fermeture” est contenu dans le mode
• ET si le mode contient “absent” → vérifier que la présence n’est PAS active

Action : activer les relais de fermeture + notification.

Option 3 — Fermeture bloquée (présence détectée)

Conditions :

• Le déclencheur est “coucher”
• ET le mode contient “absent”
• ET la présence est active (quelqu’un est là)

Action : notification uniquement — “fermeture automatique non déclenchée, présence détectée”.

Action par défaut : notification de debug (désactivée en production) pour tracer les déclenchements qui ne rentrent dans aucune condition.

Étape 4 : la bascule jour/nuit

En parallèle des volets, je maintiens une entité bascule jour/nuit (input_boolean) qui sert de signal global pour d’autres automatisations (éclairage automatique, etc.).

Nouvelle automatisation avec les mêmes deux déclencheurs (lever/coucher) :

Déclencheur "lever" → activer input_boolean.jour_nuit
Déclencheur "coucher" → désactiver input_boolean.jour_nuit

Simple, mais précieux : toutes les automatisations qui ont besoin de savoir “est-on en mode jour ?” peuvent interroger cette entité plutôt que de recalculer.

Pour afficher l’état dans le tableau de bord, un badge avec une icône soleil (allumé = jour, éteint = nuit) suffit.

Comparaison avec Jeedom

Dans Jeedom, mon scénario se déclenchait à 4h du matin et pré-calculait les heures d’ouverture/fermeture pour la journée. Moins réactif : si on changeait de mode après 4h, il fallait redéclencher manuellement.

Dans Home Assistant, l’automatisation réagit en temps réel aux entités soleil ajustées. Si on change de mode à 18h, la fermeture du soir en tiendra compte immédiatement.

La logique est similaire (test sur le contenu du mode, gestion de l’absence), mais la conception est différente. Ce n’est pas une traduction — c’est une réécriture.

Confirmation visuelle des prochaines actions

Pour savoir quand aura lieu la prochaine ouverture/fermeture, j’affiche les deux entités sensor.sun_next_rising_adjusted et sensor.sun_next_setting_adjusted comme badges dans le tableau de bord. En un coup d’œil : “demain matin à 8h52, fermeture à 17h13”.

Conseils pratiques

• Nommez vos déclencheurs — l’ID de déclenchement est indispensable dès qu’on a plusieurs déclencheurs dans une même automatisation
• Utilisez des entités template pour les calculs récurrents — plus maintenable que des formules dispersées
• La confirmation de dialogue sur les boutons d’action manuelle (ouvrir/fermer depuis le dashboard) évite les déclenchements accidentels — à activer via l’éditeur YAML de la carte tuile : confirmation: true sur la tap_action
• Testez l’historique d’exécution — HA affiche l’arbre de décision complet de chaque exécution, idéal pour débugger