1. Faits confirmés
Le volet ne se ferme plus à 22 h.
Dans ce récit fictif, la personne déclare un volet Velux. Le journal fourni mentionne un délai dépassé après un redémarrage.
Déclaration et journal de l’exemple
Débloquez votre installation Home Assistant.
Des conseils adaptés à vos équipements et à votre configuration, avec des étapes claires pour diagnostiquer, modifier et vérifier le résultat.
Chaque testeur est validé par le fondateur. Votre demande ne vaut pas acceptation.
journal collé
YAML
D’abordPuis
Tado, Velux, Sonos, Shelly, Eufy, Freebox : une seule installation, plusieurs marques.
Et ce qu’il faut pour en parler : HA OS, Raspberry Pi, mini-PC, VM, YAML, journal.
Trois temps, dans cet ordre
Le parcours prévu pour le pilote. Vous appliquez chaque changement vous-même : Homepilot n’accède pas à votre installation.
Un dossier par problème. Vous racontez ce qui se passe et joignez le YAML ou le journal que vous avez déjà. Le dossier se range dans la fiche de votre installation.
Trois listes, écrites d’abord. Les faits confirmés par vos éléments, les hypothèses à tester et les informations manquantes à recueillir.
Ce qu’il faut changer, en dernier. Une modification est proposée seulement si le test soutient l’hypothèse, avec une vérification du résultat et un retour arrière.
Exemple fictif · aucun diagnostic réel
Un dossier, lu dans l’ordre
Cas inventé pour illustrer la méthode : le volet du salon ne se ferme plus à 22 h. Les déclarations et le journal cités sont fictifs, pas des preuves de votre installation.
2. Hypothèse
L’action pourrait partir trop tôt.
L’intégration pourrait ne pas être prête au moment de l’action. Le délai dépassé ne suffit pas à confirmer cette cause.
Cause possible, non confirmée
3. Informations manquantes
Comparer la trace et le journal.
Dans Réglages → Automatisations, ouvrez l’automatisation concernée puis ses traces. Relevez l’heure de l’action et son erreur. Dans Système → Journaux, cherchez les messages Velux autour de cette heure. Ajoutez la version depuis À propos. Masquez les secrets.
Pour vérifier l’ordre des événements
4. Test
Observer avant de modifier.
Lors d’un prochain redémarrage prévu, comparez l’heure de disponibilité indiquée dans le journal à celle de l’action. Une action antérieure soutient l’hypothèse. Une action postérieure l’affaiblit. Sans ces horaires, le test reste non concluant.
Aucun changement pour ce test
5. Modification conditionnelle
Changer seulement si le test soutient la cause.
Si l’action part trop tôt, sauvegardez le YAML. Une attente de disponibilité ne peut être proposée qu’après confirmation de l’entité et de ses états. Sinon, recueillez ces éléments. Aucun délai arbitraire n’est recommandé.
Ni entité ni capacité supposée
6. Vérification et retour arrière
Vérifier le résultat, garder un retour possible.
Après une modification justifiée, contrôlez la trace, le journal et la fermeture réelle au prochain déclenchement. Vérifiez aussi après un redémarrage prévu. Si le problème persiste ou qu’un effet indésirable apparaît, restaurez le YAML sauvegardé et contrôlez son chargement.
Vous appliquez et vérifiez vous-même
La fiche d’installation reste écrite
Aperçu fictif de la fiche prévue pour le pilote. Les dossiers et la mémoire de votre installation ne sont pas encore disponibles.
Fiche d’installation · exemple fictif
exemple
Installation de l’exemple
- SystèmeHome Assistant OS sur mini-PC
- DéclaréVolet Velux dans le salon
- FaitFermeture à 22 h non obtenue, selon le récit
- FaitJournal fictif : délai dépassé après redémarrage
- HypothèseAction trop tôt ? Cause non confirmée
- ManqueVersion HA, trace et horaires de disponibilité
- SuiteObserver et tester avant toute modification
