Warum bei uns alles lokal läuft

Bevor unsere neue Home-Assistant-Installation auch nur ein Thermostat kannte, musste sie etwas versuchen, das ihr nicht gelingen durfte: den MQTT-Broker unseres Kamerasystems erreichen. Am 28. August 2026, gleich nach dem ersten Start, versuchte Claude aus dem Home-Assistant-Container heraus eine Verbindung zu diesem Broker und zur Schnittstelle des Kamerasystems. Beides lief ins Leere. FRITZ!Box und Hue-Bridge waren dagegen erreichbar. Erst danach kam das erste Gerät dazu.

Zuerst die Regeln, nach denen dieses Haus gebaut ist.

Vier Grundsätze

Lokal statt Cloud. Die erste Design-Spezifikation legt fest: kein Zugriff von außen, keine Abhängigkeit von einem Cloud-Dienst. „Fällt das Internet aus, muss das Haus weiter bedienbar sein.“ Das reicht bis in Kleinigkeiten. Die WLAN-Lichterkette von Tuya hing am Tag ihrer Einrichtung zuerst an der eingebauten, cloudgebundenen Tuya-Integration und lief noch am selben Tag lokal über tuya-local. Der Dreame-Saugroboter brauchte die Hersteller-Cloud einmal, um an seinen Token zu kommen. Dass die Integration danach trotzdem prefer_cloud: True gesetzt hatte, fiel erst auf, als das Heimschicken an einer Cloud-Störung scheiterte. Seit dem 31.08. läuft auch er im Heimnetz.

Keine laufenden Kosten. Wir haben kein Abo, weder für die Sprachsteuerung noch für den Zugriff von unterwegs. Das hat einen Preis: Anwesenheit erkennt das Haus nur über das WLAN. Die App mit GPS wäre genauer, bräuchte aber einen offenen Port, ein Abo bei Nabu Casa oder ein Dauer-VPN auf beiden Telefonen.

Isolation vor Bequemlichkeit. Home Assistant läuft in einem eigenen Docker-Bridge-Netz. Die Geräteerkennung per mDNS funktioniert dort nur eingeschränkt, also tragen wir Geräte per Adresse ein. Die mitgelieferte Integration fritz verlangt beim Einrichten das Recht „FRITZ!Box Einstellungen“, nur um den Modellnamen des Routers abzufragen, und hätte für alle 137 Geräte der FRITZ!Box einen Tracker angelegt. Gebraucht werden zwei. Stattdessen liest ein kleiner eigener Dienst nur die Geräteliste. Und die Kameras bleiben bewusst aus Home Assistant heraus.

Messen statt Vermuten. Eine Integration gilt erst als angebunden, wenn sie nachweislich tut, was sie soll. Für die FRITZ!DECT-Thermostate hieß das: den Wintergarten über Home Assistant von 17,0 auf 17,5 °C stellen, an der FRITZ!Box gegenprüfen, zurückstellen. „Eine Heizungssteuerung, die nur anzeigt, wäre wertlos.“ Seit Home Assistant nach einem Kernel-Update am 28.08. nicht von allein wieder hochkam, prüft ein Wächter alle fünf Minuten per HTTP, ob die Oberfläche antwortet, nicht nur, ob der Container läuft (mehr in Teil 7).

Der Aufbau

Alles läuft in einem Docker-Compose-Stack mit sechs Diensten:

Die Oberflächen sind nur aus dem Heimnetz erreichbar, im Router ist kein Port offen. Angebunden ist, Stand Ende September:

Die alte Hue-Bridge 1.0, seit Jahren ohne Sicherheitsupdates, kam nie in Home Assistant. Geplant war, sie übergangsweise einzubinden. Wir haben widersprochen: Beim späteren Umzug hätten sich alle Entitätskennungen geändert, jede Automation wäre gebrochen. Der Plan wurde geändert. Den Umzug der Lampen erzählt Teil 5.

Getrennt vom Kamerasystem

Auf demselben Server läuft ein eigenständiges Kamerasystem. Beide Stacks haben eigene Verzeichnisse, eigene Git-Repositories, eigene Docker-Netze und eigene MQTT-Broker. Diese Trennung war von Anfang an die oberste Anforderung.

Warum nicht den vorhandenen Broker mitbenutzen? Über ihn werden die Kameras geschaltet. Wer dort senden darf, kann eine Kamera einschalten, während jemand zu Hause ist. Ein Smart-Home-System mit Dutzenden Geräten und Community-Integrationen hat eine ungleich größere Angriffsfläche als ein abgeschottetes Kamerasystem. Ein gemeinsamer Nachrichtenkanal würde diese Angriffsfläche direkt mit den Kameras verbinden. Der zweite Broker kostet dagegen rund 10 MB Arbeitsspeicher.

Der Nachweis vom 28.08., gemessen aus dem Home-Assistant-Container:

Die Gegenprobe gehört dazu, denn eine Trennung, die alles abschneidet, wäre wertlos. Unser Statusskript wiederholt die Broker-Prüfung bei jedem Aufruf, zuletzt am 27.09. mit demselben Ergebnis.

Zwei Container laufen trotzdem im Host-Netz, der Matter-Server und die Matter-Brücke für Alexa. Matter beruht auf mDNS und UDP-Multicast, und beides verlässt ein Bridge-Netz nicht. Home Assistant, Broker und Zigbee2MQTT bleiben im Bridge-Netz. Ein eigenes Bridge-Netz schützt Container voreinander, nicht vor dem Host. Wer einen Dienst ins Host-Netz legt, prüft deshalb vorher, was der Host alles erreicht.

Im Host-Netz greift außerdem ufw, im Bridge-Netz nicht. Die Brücke brauchte deshalb eigene Freigaben, getrennt für IPv4 und IPv6. Diese und andere Netzfallen stehen in Teil 7.

Alexa ohne Abo: eine Matter-Brücke

Die naheliegenden Wege zu Alexa waren ein Cloud-Abo oder Zugriff von außen. Beides wollten wir nicht. Stattdessen läuft Home-Assistant-Matter-Hub als Matter-Brücke im Heimnetz. Alexa koppelt sie wie ein Matter-Gerät und sieht dahinter die freigegebenen Entitäten.

Freigegeben sind die Domänen light, climate und fan und einzelne Entitäten wie Fernseher und Saugroboter. Die Domäne switch pauschal hätte 14 Entitäten gebracht, davon genau ein echter Schalter; der Rest waren Konfigurationsschalter wie „Luftreiniger Display“. Sensoren bleiben draußen, bis auf zwei Gießmelder, die als Kontaktsensor eine Alexa-Routine auslösen. switch.zigbee2mqtt_bridge_permit_join steht ausdrücklich auf der Ausschlussliste, damit keine spätere Erweiterung das Zigbee-Netz per Zuruf für fremde Geräte öffnet.

Die Grenzen dieses Wegs, soweit belegt:

Lokal ist dabei die Verbindung zwischen Home Assistant und Alexa: kein weiterer Cloud-Dienst, kein offener Port. Alexa selbst bleibt ein Cloud-Dienst. Wie sehr das zählt, zeigte der Küchenentfeuchter: Am 20.09. sollte er über Alexa und die Cloud einer WLAN-Steckdose geschaltet werden. Fiele ein Glied dieser Kette aus, würde nichts schalten, und Home Assistant merkte es nicht. Wir haben das am selben Tag zurückgenommen, heute schaltet eine Zigbee-Steckdose (Teil 6).

Wo doch eine Cloud im Spiel ist

„Alles lokal“ stimmt nicht ganz. Die Ausnahmen:

Die tägliche Sicherung

Die Sicherung stand im ersten Plan als Aufgabe 5 und blieb beim Sprung in die Zigbee-Arbeit liegen. Nachgeholt wurde sie am 29.08., als schon sechs Zigbee-Geräte angelernt waren. Das wog schwer: Im Verzeichnis von Zigbee2MQTT steht der Netzwerkschlüssel. Geht er verloren, muss jedes Gerät neu angelernt werden, jede Hue-Lampe mit Touchlink-Reset direkt an der Lampe.

Seitdem packt sichere-konfiguration.sh täglich per cron ein Archiv: .env, docker-compose.yml, die Konfiguration von Home Assistant samt Zusatzintegrationen, das Zigbee2MQTT-Verzeichnis, die Broker-Konfiguration, Dokumentation und Git-Repository. Nicht enthalten sind die Verlaufsdatenbank, Protokolle und die Daten des Brokers.

Die Verschlüsselung ist Pflicht: Im Archiv stehen alle Zugangsdaten aus der .env und die Schlüssel der lokal angebundenen Geräte. Hier gibt es eine bewusste Ausnahme von der Trennung: Die Sicherung nutzt denselben verschlüsselten Zugang wie das Kamerasystem, mit eigenem Ordner. Das betrifft nur die Sicherung, nicht den Betrieb, und erspart ein zweites Passwort.

Die Wiederherstellung haben wir am 29.08. aus der Cloud geprobt, nicht von der lokalen Platte: Geräte, Netzwerkschlüssel, Zusatzintegration des Saugroboters und Git-Historie waren da. Bis zum 27.09. zählt das Protokoll 29 Läufe mit je 28 bis 29 MB, alle übertragen, kein Fehler. Das Statusskript warnt, wenn der jüngste Stand älter als 30 Stunden ist.

Wie wir arbeiten

Jeder größere Schritt beginnt mit einer Design-Spezifikation und einem Umsetzungsplan. Die ersten Commits:

Die Spezifikation beschreibt Ziel, Umfang, Architektur, Risiken und woran der Erfolg gemessen wird. Ihr Status: „Entwurf zur Freigabe“. Der Plan zerlegt sie in Aufgaben mit Prüfschritten. Die Heizung bekam am 31.08. eine eigene Spezifikation und einen Plan in sieben Aufgaben.

Jede Änderung ist mit Datum und Begründung festgehalten: 138 Commits bis zum 27.09., 15 Dokumentationsdateien mit knapp 5 900 Zeilen. Was sich als falsch herausstellt, bleibt sichtbar. Ein Abschnitt beginnt mit „Zurückgenommen am selben Tag“, ein anderer mit „Kehrtwende“, weil eine Recherche vom Vormittag falsch war.

Geändert wird erst, wenn wir zugestimmt haben. Das Nutzungsprofil der Räume haben wir bestätigt, bevor es in die Heizungsspezifikation einging. Ein Schalter für den Saugroboter wurde auf unseren Wunsch zurückgebaut, weil wir erst selbst die Alexa-App durchsehen wollten. Noch am selben Tag kam er zurück, laut Commit „diesmal aus belegtem Grund“.

Die Arbeit am Server hat Claude erledigt: Protokolle lesen, messen, Konfiguration schreiben, dokumentieren, committen. Wir haben entschieden und oft widersprochen. Wie das im Alltag aussieht und wo es schiefging, erzählt Teil 8.

Wie es weitergeht

Teil 2 verfolgt ein kaltes Büro bis zu drei Ursachen. Teil 3 zeigt, wie zwei Ventilsysteme im selben Haus zusammenfinden, Teil 4, warum der Heizplan nicht der Heizbeginn ist. Teil 5 geht durch den Zigbee-Alltag nach dem Koppeln, Teil 6 durch Taupunkt, Entfeuchter und Luftreiniger. Teil 7 sammelt die Fallen in Docker, Netzwerk und Home Assistant, Teil 8 das, was nicht geklappt hat.

Was wir mitnehmen

• Die Trennung zuerst nachweisen, vor dem ersten Gerät, und immer mit Gegenprobe.
• Ein eigenes Bridge-Netz schützt Container voreinander, nicht vor dem Host. Wer einen Dienst ins Host-Netz legt, prüft vorher, was der Host alles erreicht.
• Ein zweiter MQTT-Broker kostet rund 10 MB Arbeitsspeicher. Ein gemeinsamer wäre ein Schaltweg vom Smart Home zu den Kameras.
• Eine Matter-Brücke bringt Alexa ohne Abo ins Haus, aber nur mit dem, was Alexa als Matter-Gerätetyp kennt. Kennungen festlegen, bevor sie an die Brücke gehen: Umbenennen ist in Home Assistant billig und in Alexa teuer.
• Der Zigbee-Netzwerkschlüssel ist das wertvollste Stück der Sicherung. Die Wiederherstellung aus der Cloud proben, nicht nur sichern.
• Cloud-Ausnahmen aufschreiben statt wegreden. Dann weiß man, was bei einem Internetausfall stillsteht.