Die Konfiguration, die sich selbst ausrollt
Home Assistant holt seine Konfiguration alle fünf Minuten aus Git. Kein Deploy-Job erreicht es.
Holen statt schicken
Im Container der Zentrale läuft eine geforkte Deploy-Integration, die den
main-Branch beobachtet, ihn alle fünf Minuten holt und in sein eigenes
Konfigurationsverzeichnis mergt. Es gibt keinen Deploy-Job und keine
Login-Schnittstelle: Nichts aus der CI erreicht die laufende Instanz.
Nach einem Pull wird ein Event ausgelöst, und eine in Git verwaltete
Automatisierung wendet ihn an — ein Reload oder ein vollständiger Neustart, wenn sich die
Kernkonfiguration oder der Code einer Integration geändert hat. Ein Merge auf
main kann das Haus neu starten.
Was die CI prüft
Die Konfigurationsprüfung startet den eingebauten Check von Home Assistant im offiziellen Image, per Tag und Digest auf die Version gepinnt, die in Produktion läuft, und sie blockiert den Merge Request. Home Assistant protokolliert einen schemawidrigen Eintrag, deaktiviert genau diesen Eintrag und macht weiter, sodass nur ein Syntaxfehler oder ein Fehler im Kernblock einen Fehlercode liefert. Deshalb wird das mitgeschriebene Log zusätzlich nach den bekannten Fehlermeldungen durchsucht. Ein eigener Job prüft die gesamte Git-Historie auf Zugangsdaten.
Jeder Konfigurationseintrag einer Integration und alle Zugangsdaten liegen im eigenen Speicher der Zentrale, bewusst nicht versioniert.
Die auf der Zentrale installierten Drittanbieter-Integrationen aktualisieren sich in einem wöchentlichen Fenster am Sonntagvormittag selbst. Das Fenster ist bewusst schmal. Es lässt Firmware jeder Art aus, denn ein OTA-Update würde die hier geschriebene Lampen-Firmware überschreiben, die Zugangsdaten von den Sensorknoten löschen und einen Entwicklungsstand auf den Funk-Koordinator schieben. Es lässt ein Update aus, das das NAS neu startet. Und es lässt die Handvoll Komponenten mit lokalen Patches aus, denn eine Installation darüber überschreibt den Patch.
Am 24. August 2026 wurde die Update-Entität des Herstellers ausgelöst; sie spielte die Original-Firmware auf, die keinerlei Zugangsdaten enthält, mit denen irgendetwas die Hardware noch erreichen könnte, und alle vier Apollo-Multisensor-Knoten verschwanden auf einmal aus dem Netz. Diese Entität und der Firmware-Knopf des Herstellers sind auf allen acht Hersteller-Knoten inzwischen ausgeblendet — wer nur die Entität ausblendet, bleibt vom selben Flash nur einen Tastendruck entfernt, weil der Knopf ihn aufruft. Bei den Knoten blieb es nicht beim Ausblenden: Der eigene Web-Updater der Firmware ist ganz abgeschaltet, und der Fallback-Access-Point, den jeder Knoten aufspannt, wenn er das Netz nicht findet, trägt jetzt ein Passwort — derselbe Flash lässt sich also gar nicht mehr per Funk auslösen.
Was fehlt und was geplant ist
- Die externe Sicherung wurde entschlüsselt und isoliert gestartet; ein Neuaufbau von null auf eine leere Maschine noch nicht. Der Bootstrap spielt den nicht versionierten Zustand aus der externen Sicherung in ein leeres Konfigurationsverzeichnis zurück, entschlüsselt mit dem dafür verwahrten Notfallschlüssel; danach übernimmt die Synchronisation.
- Geplant: einmal alle physischen Bedienelemente durchgehen — jeden Knopf, jeden Drehregler und jedes Pad inventarisieren, dann die Zuordnung pro Raum entscheiden, zusammen mit dem Abschalten der Lichtautomatiken, die noch in einer Hersteller-Bridge laufen, damit nie zwei Systeme dieselben Lampen steuern.