¶ Administration
Cinq écrans, réservés au rôle Administration même en lecture.
Le sommaire donne l'état de chacun d'un coup d'œil : nombre de comptes, mode
d'authentification, état de Home Assistant, moteur de base et dernière
sauvegarde, mode développement actif ou non, niveau de journal. Les alertes qui
comptent — mot de passe par défaut encore en place, connexions en échec —
remontent ici.
¶ Comptes et rôles
Traité en détail dans Authentification et rôles.
¶ Réglages et connexions
Quatre blocs — Home Assistant, Authentification, Base de données, Divers —
chacun avec son bouton Tester.
C'est le point du logiciel où l'on répare le plus souvent, donc le point où l'on
teste : une configuration qu'on ne peut pas éprouver se vérifie au pire moment,
pendant un déploiement.
| Bouton | Ce qu'il vérifie |
|---|---|
| Tester (Home Assistant) | instance joignable, jeton accepté, composants chargés, API WebSocket et registres |
| Tester l'écriture | écrit une automatisation marquée, sans déclencheur ni action, puis la supprime — seul test concluant du prérequis automation: !include automations.yaml |
| Tester Keycloak | récupère le document de découverte et dit ce qui manque |
| Tester (base) | ouvre une connexion et lit la révision de schéma |
Ces réglages sont écrits dans data/settings.json, à l'intérieur du volume de
données : ils survivent au redémarrage et au remplacement du conteneur, et
l'emportent sur le fichier .env. Voir Configuration.
Le niveau de journal se change ici, sans redémarrer.
¶ Base de données et sauvegardes
Le premier bloc dit ce qui tourne : moteur, URL, révision de schéma, taille du
fichier, et le détail table par table du contenu. C'est la réponse à « est-ce
que j'ai bien restauré ce que je croyais ».
¶ La sauvegarde est une archive JSON
Table par table, ligne par ligne, valeurs converties en types JSON. Ce n'est pas
un pg_dump, et c'est délibéré :
- une archive JSON se restaure dans n'importe quel moteur, ce qui fait de la
migration SQLite → PostgreSQL exactement la même mécanique qu'une restauration
— donc une mécanique éprouvée à chaque test, au lieu d'un outil à part qu'on
n'exercerait jamais ; - elle se lit, et se corrige, à la main.
Les fichiers vivent dans data/sauvegardes/.
Gardez-en une copie ailleurs. Une sauvegarde posée à côté de la base ne
protège pas d'un disque perdu.
¶ Ce que la restauration garantit
- une sauvegarde de sécurité est prise d'abord (
avant-restauration-…) ; - une archive faite sur une autre révision de schéma est refusée, pas
tentée : insérer des lignes dans un schéma qui a changé est le meilleur moyen
de perdre des données en croyant les sauver ; - une colonne ou une table inconnue est refusée plutôt qu'ignorée en silence ;
- si l'archive ne contient aucun administrateur actif, le compte de secours est
recréé — sinon la console deviendrait inaccessible.
¶ Passer à PostgreSQL
- créer une base vide et un utilisateur côté PostgreSQL (l'application ne
les crée pas) ; - saisir l'URL cible,
postgresql+asyncpg://utilisateur:motdepasse@hôte:5432/base; - Tester la cible — la question « est-ce que ça répond » se pose avant de
copier, pas pendant ; - Copier les données vers cette base.
La copie ne touche pas à la base d'origine, et la bascule ne prend effet qu'au
redémarrage : l'URL est enregistrée dans data/settings.json, mais le
processus en cours continue sur l'ancienne base. On peut donc vérifier la
nouvelle base avant de s'y engager, et Annuler la bascule remet tout comme
avant sans rien perdre.
Changer de moteur sous les pieds d'un processus en cours de requête serait un
risque gratuit.
Les mots de passe d'URL ne s'affichent nulle part : ni à l'écran, ni dans les
messages d'erreur, ni dans le journal.
¶ Remise à zéro
Même écran, tout en bas, volontairement à part. Deux portées :
| Portée | Efface | Conserve |
|---|---|---|
| Plannings, périodes et historique | plannings, jours-types, étapes, périodes, déploiements | équipements et libellés |
| Tout le contenu | en plus : référentiel matériel et journaux d'activité | — |
Dans les deux cas, les comptes et les réglages ne sont jamais touchés : une
remise à zéro qui vous déconnecte de votre propre application, ou qui efface le
jeton Home Assistant, transforme un nettoyage en réinstallation.
Trois garde-fous :
- l'opération est refusée si une période a encore des automatisations dans Home
Assistant (déployée ou désactivée). Les oublier les laisserait tourner dans
la maison sans que l'application s'en souvienne. Il faut retirer la période
d'abord ; - une sauvegarde
avant-remise-a-zero-…est prise systématiquement ; - il faut recopier le mot
REINITIALISER— une case à cocher se coche sans
lire.
Aucun ordre n'est envoyé à Home Assistant : la remise à zéro est purement locale.
¶ Mode développement
Deux situations, et c'est la seconde qui compte.
Avec une instance Home Assistant joignable, on capture d'abord les
équipements réels — en lecture seule, états et registres, rien de plus — puis on
se débranche. On travaille ensuite sur cette photographie : ses libellés, ses
pièces, ses pièges. C'est ce qui permet d'éprouver un déploiement complet avec
son propre matériel sans toucher aux volets.
Sans instance, le simulateur démarre sur un jeu d'équipements par défaut qui
reprend les mêmes pièges : un éclairage branché sur une prise (domaine switch)
et une entité indisponible.
Le simulateur répond en API REST et en API WebSocket, poignée de main
d'authentification comprise, et se branche comme un simple transport : le client
Home Assistant ne sait pas qu'il ne parle pas à une vraie instance. Un simulateur
ayant sa propre voie d'exécution ne prouverait rien.
La photographie est enregistrée dans data/dev_snapshot.json — conservée au
redémarrage, et lisible à la main pour bricoler un cas de test.
Ce qui a été « déployé » dans le simulateur n'existe pas dans la maison.
Rebrancher Home Assistant ne l'y transporte pas : il faut relancer un vrai
déploiement.
Un bandeau ambre rappelle en permanence que le mode est actif, avec le bouton
Rebrancher Home Assistant.
¶ Journaux
Trois questions qu'on se pose à des moments différents, donc trois vues :
| Vue | Répond à | Source |
|---|---|---|
| Connexions | qui est entré, depuis où, qui a échoué | table d'audit |
| Activité | qui a fait quoi : déploiements, comptes, réglages, sauvegardes | table d'audit |
| Journal applicatif | pourquoi ça a échoué | fichier de log |
¶ Le journal applicatif
Écrit dans data/logs/scenario-studio.log (réglable par LOG_FILE) en plus
de la sortie standard. C'est nécessaire : la sortie d'un conteneur n'est pas
relisible depuis l'application, et c'est justement quand on n'a pas accès au
terminal qu'on a besoin de la lire.
Le fichier tourne par taille — 2 Mio, trois archives — il ne remplira pas le
disque et il n'y a rien à purger.
Deux détails qui font la différence à l'usage :
- une trace d'exception reste rattachée à son entrée, dépliable d'un clic. La
vraie cause d'un échec est là, pas dans le message résumé affiché à l'écran ; - le fichier est lu par la fin, et seule la fin est analysée. Un journal de
plusieurs mégaoctets n'immobilise donc pas l'écran.
¶ Purge de l'audit
Les entrées anciennes se purgent depuis l'écran, avec un minimum de sept jours
de rétention : purger les entrées récentes effacerait la trace de ce qui vient
de se passer. La purge est elle-même consignée.
¶ L'alerte de connexions
Si plus de cinq connexions échouent en 24 heures pour moins de connexions
réussies, une alerte apparaît sur l'écran des journaux et sur le sommaire de
l'administration, avec les adresses concernées.
¶ Aller plus loin
¶ Sommaire de la documentation
- Accueil Domodrive
- Domodrive — présentation
- 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 (page courante)
- 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é).