¶ Domodrive — présentation
Domodrive est un atelier de scénarios domotiques pour Home Assistant. On y
dessine des plannings horaires d'actions sur les volets et les éclairages, on les
valide, on les traduit en automatisations Home Assistant, on les déploie sur une
plage de dates, puis on les retire proprement.
Cas d'usage fondateur : partir deux semaines en vacances avec une
simulation de présence crédible, dessinée à la souris, déployée en un clic,
retirée proprement au retour.
L'interface de l'application porte le nom Scénario Studio : c'est le même
logiciel. Domodrive est le nom du projet, du dépôt et de l'image Docker.
¶ La règle qui commande tout le reste
L'application n'allume jamais une lumière et ne bouge jamais un volet. Elle
écrit des automatisations dans Home Assistant ; c'est Home Assistant qui exécute.
Ce n'est pas une intention affichée, c'est vérifiable : le client Home Assistant
n'émet que trois appels de service, tous du domaine automation —
automation.turn_on, automation.turn_off, automation.reload. Aucun appel
light.* ni cover.* ne part de l'application. Les services cover.open_cover
et compagnie n'existent qu'à l'intérieur du YAML qu'elle produit.
Trois conséquences voulues :
- un scénario déployé tient tout seul. Les bornes de dates sont dans la
condition de l'automatisation, pas dans un ordonnanceur côté application.
Domodrive peut être éteint pendant les deux semaines d'absence ; - le pilotage par position est interdit dans tout le projet. Aucun volet
n'est supposé calibré — bug connu des modules Sonoff — donc jamais de
set_cover_position. Une fermeture partielle est unclose_cover, une
attente, puis unstop_cover; - l'application ne touche jamais une automatisation qu'elle n'a pas créée.
Le marquagescnstudio_/[SCN]est le seul critère qui l'autorise à
écrire ou à supprimer.
¶ Les deux façons de décrire un comportement
C'est la distinction structurante de l'application.
| Étape de planning | Routine de contrôle | |
|---|---|---|
| Déclenchée par | une heure | une situation |
| Exemple | à 07:15, ouvrir le volet | s'il fait plus de 25 °C dehors et plus de 500 lx dans la chambre, fermer le volet |
| Sert à | simuler une présence | protéger du soleil, de la chaleur |
| Vit dans | un jour-type d'un planning | une bibliothèque, placée dans les plannings |
| Déclencheur Home Assistant | platform: time |
platform: numeric_state, ouverture de fenêtre horaire, démarrage de HA |
Les deux cohabitent dans un même planning et peuvent viser le même volet.
¶ Les écrans
| Écran | Ce qu'on y fait |
|---|---|
| Tableau de bord | ce qui tourne aujourd'hui, l'état de Home Assistant, la désactivation d'urgence |
| Plannings | liste et éditeur : grille, jours-types, étapes, actions, routines placées, validateur, journée simulée |
| Contrôles | bibliothèque de routines environnementales |
| Périodes | déploiement, désactivation, retrait ; aperçu du YAML et diff ; calendrier des exceptions ; historique |
| Équipements | référentiel, rattachement en lot, capteurs, synchronisation |
| Orphelins | automatisations scnstudio_ présentes dans Home Assistant mais absentes de la base |
| Administration | comptes, réglages, base et sauvegardes, mode développement, journaux |
Chaque section porte sa couleur — ciel pour les plannings, ambre pour les
équipements, émeraude pour les périodes — reprise sur les titres, les cartes et
le bouton d'action de ses écrans.
¶ Ce que l'application ne fait pas
- elle ne pilote pas les équipements (voir plus haut) ;
- elle ne modifie jamais
configuration.yaml, ne crée aucun helper, aucun
script, aucune entrée de registre ; - elle n'arbitre pas entre deux automatisations : c'est Home Assistant qui
exécute, et la dernière déclenchée gagne. Le validateur signale les
contradictions qu'il sait démontrer, il ne peut pas les supprimer ; - elle ne surveille rien en permanence : les routines réagissent à des
événements, jamais à une scrutation périodique.
¶ Où trouver quoi
| Vous voulez | Page |
|---|---|
| Installer avec Docker | Installation Docker |
| Installer sur Kubernetes | Installation Kubernetes |
| Régler l'application | Configuration et options |
| Gérer les accès | Authentification et rôles |
| Faire son premier scénario | Prise en main |
| Comprendre l'éditeur | Plannings |
| Protéger du soleil | Routines de contrôle |
| Déployer et retirer | Périodes et déploiement |
| Sauvegarder, migrer, auditer | Administration |
| Diagnostiquer une panne | Exploitation et dépannage |
| Regarder sous le capot | Référence technique |
¶ Le projet en chiffres
| Version | 1.0.0 |
| Code source | ~16 600 lignes, 70 modules Python |
| Tests | ~16 100 lignes, 1014 tests |
| Gabarits | 48 fichiers, ~4 900 lignes |
| Tables | 16, pour 3 migrations |
| Points d'entrée HTTP | 130 |
| Dépendances de production | 15 |
| Étape de compilation front | aucune |
¶ Dépôt et image
- Code source : https://gitlab.ev1.fr/ev1/domodrive — dépôt privé, l'accès
se demande à son propriétaire. - Image Docker :
suntux57420/domodrive:1.0.0etsuntux57420/domodrive:latest
sur Docker Hub.
¶ Sommaire de la documentation
- Accueil Domodrive
- Domodrive — présentation (page courante)
- Installation avec Docker
- Installation sur Kubernetes
- Configuration et options
- Authentification et rôles
- Prise en main
- Plannings
- Routines de contrôle environnemental
- Périodes et déploiement
- Administration
- Exploitation et dépannage
- Référence technique
Documentation Domodrive 1.0.0 — copie conforme du répertoire docs/ du dépôt gitlab.ev1.fr/ev1/domodrive (dépôt privé).