Domotique : Home Assistant sur installation KNX

Projet personnel. La configuration est versionnée dans un dépôt privé et exploitée avec la même discipline opérationnelle qu’une infrastructure de production.

L’installation

Home Assistant OS est déployé au-dessus d’une installation KNX filaire : éclairages, volets et variation communiquent sur un bus standardisé, exposés dans une interface unifiée. Autour du bus, environ 800 entités : prises connectées en Matter avec mesure par prise, capteurs MQTT, passerelles HomeKit pour la commande vocale, pilotage TV et médias. Tout fonctionne en local, sans dépendance au cloud.

Ingénierie inverse du bus KNX

L’installation précède le projet et sa programmation ETS d’origine n’était pas fiable. Plutôt que de croire la documentation (règle de travail : la vérité, c’est le bus, pas le fichier), l’audit croise le projet ETS exporté avec des captures du trafic réel pour reconstruire la topologie effective : adresses fantômes jamais câblées, un circuit d’éclairage mort, des détecteurs de mouvement jamais reliés à une adresse de groupe, des positions de volets estimées par temps de course faute de retour d’état.

Chaque anomalie a été suivie comme un problème numéroté. Celles qui exigeaient un accès ETS sont devenues une spécification factuelle remise à l’intégrateur KNX : preuve par équipement à partir des captures de télégrammes, tâches délimitées, résultats attendus écrits sous forme de traces. En parallèle, des boutons poussoirs orphelins ont été recyclés via des déclencheurs sur télégrammes bruts dans Home Assistant, pour restaurer des comportements qu’aucun actionneur n’écoutait.

Interphone et portail : intégration matérielle sur mesure

L’interphone est un modèle audio analogique deux fils, sans caméra ni API, et le moteur de portail ne se commande que par contact sec. Un ESP32 sous ESPHome fait le pont sans rien remplacer : un relais monté en parallèle du poussoir existant envoie l’impulsion d’ouverture, bornée à 500 ms dans le firmware, et un étage de redressement piqué sur la paire écouteur du combiné rend la sonnerie lisible par le microcontrôleur. Le signal d’appel étant trop faible pour un seuil logique, la détection passe par une mesure ADC comparée en logiciel, le niveau brut restant exposé comme capteur pour repérer toute dérive. La sonnerie déclenche une notification critique sur iPhone, avec ouverture du portail en une action protégée par Face ID, et le portail est exposé en accessoire HomeKit pour la commande vocale.

Accès distant zero-trust

L’accès distant repose sur un maillage WireGuard, sans exposition publique de l’installation, avec trois niveaux strictement séparés : les membres du foyer n’atteignent que l’interface, le mainteneur dispose d’un canal d’administration dédié, les invités restent en local uniquement. L’ensemble a fait l’objet d’une passe de durcissement et d’audits d’accès réguliers, le tout documenté en runbook. Coût récurrent : zéro.

Observabilité énergétique

Le compteur Linky alimente le tableau de bord énergie via un double pipeline : statistiques long terme injectées par l’API WebSocket, plus capteurs MQTT pour les valeurs en direct, avec un script Python de smoke test qui valide les deux chemins. Le comptage par prise en Matter est agrégé par des utility meters en cycles jour, mois et année, tracé par des data generators ApexCharts sur mesure qui interrogent directement l’API de statistiques du recorder. Une jauge carbone suit en temps réel la part d’électricité décarbonée du réseau.

Exploitée comme en production

• Configuration as code : conventional commits, workflow branche et pull request, surface versionnée volontairement limitée aux fichiers écrits à la main. Secrets, état machine et sorties de gestionnaires de paquets restent hors de Git.
• Runbooks : un runbook d’accès distant de 700 lignes avec décision d’architecture, procédure de révocation, table de dépannage et vérification périodique en deux minutes.
• Mises à jour : montée de version mensuelle automatisée des add-ons avec sauvegarde partielle avant chaque installation et rapport d’échec ; le cœur du système reste en manuel, sur notification.
• Sauvegardes : snapshots hebdomadaires chiffrés vers deux destinations, locale et cloud, avec un partage explicite : Git couvre la configuration, les sauvegardes couvrent le système.
• Monitoring : alertes à paliers sur la santé du système et la consommation électrique, avec notifications critiques qui contournent le mode silencieux.
• Self-healing : la détection de perte de lien déclenche un rechargement d’intégration au lieu d’attendre la fin des backoffs de reconnexion.

Opérations assistées par IA

L’exploitation est assistée par un agent IA, et cette assistance est configurée avec la même rigueur que le reste de l’infrastructure. Le dépôt versionne un brief projet complet qui cadre l’agent : contexte de l’installation, conventions d’exploitation, périmètre de permissions restreint et garde-fous explicites distillés de l’expérience terrain (vérifier l’état réel avant de proposer un changement, préciser le rechargement requis pour chaque modification, confirmer toute action sensible). Des serveurs MCP exposent l’installation vivante à l’agent, mis à contribution pour les audits, le diagnostic et la rédaction. Je pilote le workflow de bout en bout, j’arbitre les choix d’architecture et j’engage chaque changement en connaissance de cause. Un cas concret de context engineering, où l’IA démultiplie mon expertise sans jamais s’y substituer.

Ce que le projet démontre

Réseau, protocoles, architecture de sécurité, électronique embarquée, observabilité et automatisation opérationnelle, appliqués de bout en bout sur du matériel réel et tenus aux standards de la production. Les mêmes réflexes (auditer avant de changer, préférer les preuves à la documentation, moindre privilège, runbooks et plans de rollback) se transfèrent directement à l’exploitation de systèmes LLM en production.