Quand la synchronisation ou le déploiement échoue, avant toute autre chose :
# en conteneur
docker compose exec app python -m scenario_studio.diagnose
# sur Kubernetes
kubectl -n domodrive exec deploy/domodrive -- python -m scenario_studio.diagnose
# depuis les sources
.venv/bin/python -m scenario_studio.diagnose
Le diagnostic ne modifie rien. Il vérifie chaque maillon l'un après l'autre —
configuration, URL WebSocket déduite, instance joignable, jeton accepté,
composants chargés, API WebSocket et registres — et dit lequel ne répond pas.
Diagnostic de la connexion à Home Assistant
------------------------------------------------------------
[--] URL de base : http://homeassistant.local:8123
[--] Jeton : renseigné
[--] Fuseau : Europe/Paris
[--] URL WebSocket : ws://homeassistant.local:8123/api/websocket
[ok] Instance joignable
[ok] Jeton accepté
…
python -m scenario_studio.diagnose --test-ecriture
Écrit une automatisation marquée, sans déclencheur ni action — donc incapable
de piloter quoi que ce soit — puis la supprime immédiatement. C'est le seul test
concluant du prérequis automation: !include automations.yaml.
Le même test est disponible depuis Administration → Réglages → Tester
l'écriture.
| Vérifier | Comment |
|---|---|
| Les domaines demandés | HA_SYNC_DOMAINS contient-il bien light,switch,cover ? |
| Le jeton | Tester dans les réglages : un jeton révoqué donne 401 |
| Les entités existent | l'instance expose-t-elle réellement des volets ou des éclairages ? |
Les capteurs, eux, remontent toujours, quel que soit HA_SYNC_DOMAINS.
Presque toujours le prérequis manquant :
# configuration.yaml de Home Assistant
automation: !include automations.yaml
Le tableau de bord affiche ce diagnostic. Après ajout, redémarrer Home Assistant.
Le validateur a trouvé une erreur. Elle est affichée juste au-dessus, avec un
lien Corriger dans l'éditeur. Les avertissements et les informations, eux, ne
bloquent rien.
L'entité a disparu de Home Assistant, ou son entity_id a changé. L'application
ne l'efface jamais : elle la marque indisponible, pour que le problème se voie
au lieu qu'une ligne de planning s'évapore.
Trois issues :
[SCN] traînent dans Home Assistant »Écran Orphelins : il liste les automatisations scnstudio_ présentes dans
Home Assistant mais absentes de la base, et les nettoie. C'est le cas après un
déploiement interrompu ou une base restaurée à un état antérieur.
Tableau de bord → Désactiver en urgence. Les automatisations restent écrites
mais sont éteintes immédiatement. Ensuite, à tête reposée : Périodes →
Retirer de Home Assistant.
Regarder les toutes premières lignes du journal. Deux refus explicites :
| Message | Cause |
|---|---|
AUTH_MODE=dev refusé |
ENV=production avec le mode sans authentification |
SECRET_KEY refusée |
valeur d'exemple ou trop courte, avec ENV=production |
Ces refus sont volontaires : un défaut bruyant se corrige, un défaut toléré ne se
voit jamais.
Attendu. La clé de chiffrement des secrets persistés en dérive : le jeton Home
Assistant et le secret client OIDC doivent être ressaisis depuis l'écran de
réglages. L'application le dit plutôt que d'échouer en silence.
Les comptes locaux restent utilisables : c'est exactement le cas qu'ils
couvrent. Se connecter en local, aller dans Réglages → Authentification,
corriger, et Tester Keycloak.
Si aucun compte local ne fonctionne non plus, restaurer une sauvegarde : si
l'archive ne contient aucun administrateur actif, le compte de secours est
recréé automatiquement.
| Question | Où regarder |
|---|---|
| Pourquoi ça a échoué ? | Administration → Journaux → Journal applicatif (la trace d'exception est dépliable) |
| Qui a fait ça ? | Journaux → Activité |
| Qui est entré ? | Journaux → Connexions |
| Qu'est-ce qui tournait la semaine dernière ? | Périodes → Historique, avec l'instantané YAML |
curl -s http://localhost:8000/health
{"status":"ok","version":"1.0.0","env":"production","auth_mode":"local",
"timezone":"Europe/Paris","database":"ok","ha_configured":true}
Sans authentification, sans secret exposé. C'est l'URL des sondes de l'image
Docker et des livenessProbe / readinessProbe Kubernetes, et celle à donner à
un superviseur externe.
Administration → Base et sauvegardes → Sauvegarder maintenant. L'archive
JSON atterrit dans data/sauvegardes/ — récupérez-la ailleurs.
Une restauration prend d'abord une sauvegarde de sécurité, refuse une archive
faite sur une autre révision de schéma, et refuse une colonne inconnue plutôt que
de l'ignorer.
Le détail est sur la page Administration.
docker compose pull && docker compose up -d
# ou
kubectl -n domodrive set image deploy/domodrive domodrive=suntux57420/domodrive:<version>
Les migrations s'appliquent au démarrage. Prenez une sauvegarde avant, et
récupérez le fichier : une montée de version est exactement le moment où l'on
regrette de ne pas l'avoir fait.
Le mode développement débranche Home Assistant et bascule sur un simulateur
interne, éventuellement alimenté par une photographie de votre vrai matériel.
Tous les déploiements y vont ; la maison ne bouge pas. Voir
Administration.
C'est ce qu'il faut activer avant de tester une manipulation dont on n'est pas
sûr.
Documentation Domodrive 1.0.0 — copie conforme du répertoire docs/ du dépôt gitlab.ev1.fr/ev1/domodrive (dépôt privé).