Home Assistant zuverlässiger machen: Schaltlogik raus aus dem Server

Wie macht man Home Assistant zuverlässiger?

Die kurze Antwort, gleich vorweg: indem man Home Assistant als Gehirn behandelt und nicht als Rückenmark. Die Basis-Schaltlogik (Taster drückt, Licht geht an) wandert direkt in die Geräte oder zwischen die Geräte: als ESPHome-Automation auf dem Mikrocontroller, als Zigbee-Binding vom Taster zur Lampe, als Z-Wave-Assoziation. Home Assistant behält alles, was wirklich Hirn braucht: Kontext, Szenen, Statistik, das Dashboard. Und wenn der Server gerade ein Update einspielt, neu startet oder schlicht tot ist, schaltet das Licht in der Dusche trotzdem.

Das ist die ganze These dieses Posts. Der Rest ist die Begründung, zwei konkrete Bauanleitungen und eine ehrliche Tabelle, was welcher Weg kann.

Warum mich das Thema nicht loslässt: Home Assistant ist längst keine Bastelei mehr, sondern Infrastruktur. Über 654.000 aktive Installationen melden sich freiwillig bei der Projekt-Statistik, und das ist nur der Opt-in-Anteil, die Dunkelziffer liegt deutlich höher. Infrastruktur wird aber nicht am Dashboard gemessen, sondern am Lichtschalter. Ein Lichtschalter von 1975 hat eine Verfügbarkeit, über die jeder Software-Stack nur staunen kann. Wer smarte Technik einbaut, tritt gegen dieses Erwartungsniveau an, ob er will oder nicht.

Das Nadelöhr zwischen Taster und Lampe

Geh einmal in Zeitlupe durch, was in einem typischen Setup passiert, wenn jemand auf einen Zigbee-Taster drückt. Der Taster funkt an den Koordinator-Stick. Der Stick reicht das Telegramm an Zigbee2MQTT weiter. Zigbee2MQTT publiziert auf den MQTT-Broker. Home Assistant abonniert das Topic, eine Automation feuert, ruft light.turn_on, und der Befehl nimmt denselben Weg zurück: Broker, Zigbee2MQTT, Stick, Funk, Lampe.

Das sind, je nach Zählweise, sieben Stationen für „Licht an”. Jede davon ist ein Prozess, der laufen muss. Jede hat Updates. Mehrere teilen sich dieselbe SD-Karte, dieselbe Disk, denselben kleinen Rechner im Flur. Fällt eine Station aus, ist nicht eine Komfortfunktion weg, sondern der Lichtschalter. Wie sich so ein Ausfall anfühlt, wenn er zur Unzeit kommt, habe ich in der Geschichte der Z2M-Kaskade an einem Donnerstagnachmittag aufgeschrieben — seitdem denke ich bei jeder Automation darüber nach, was passiert, wenn die Kette reißt.

Wichtig: Das ist kein Vorwurf an Home Assistant. Der Stack ist erstaunlich stabil, und die allermeisten dieser sieben Stationen laufen monatelang ohne Mucken. Aber Stabilität ist nicht dasselbe wie Unabhängigkeit. Ein Update bleibt ein Update, ein Neustart bleibt ein Neustart, und beides gehört zum ehrlichen Betrieb dazu. Die Frage ist nicht, ob der Server mal kurz weg ist. Die Frage ist, was in diesem Moment noch funktioniert.

Gehirn und Rückenmark

Der menschliche Körper hat dieses Problem elegant gelöst. Wenn du auf eine heiße Herdplatte fasst, zieht der Reflexbogen die Hand zurück, bevor das Signal überhaupt im Gehirn ankommt. Das Rückenmark entscheidet. Das Gehirn erfährt es kurz danach und darf sich dann um das Interessante kümmern: fluchen, Ursache analysieren, beim nächsten Mal vorsichtiger sein.

Genau diese Arbeitsteilung will ich im Haus, denn sie macht Home Assistant zuverlässiger, ohne ihm etwas wegzunehmen. Reflexe (Taster schaltet Licht, Schalter fährt Rollladen) gehören auf die unterste Ebene, die noch funktioniert: in den Mikrocontroller, ins Funkprotokoll, notfalls in die Klemme. Das Gehirn macht Kontext: nachts nur 20 Prozent Helligkeit, Rollladen runter bei Sonne auf der Westseite, Heizung aus, wenn niemand zu Hause ist. Fällt das Gehirn aus, verliert das Haus seine Intelligenz, aber nicht seine Grundfunktion.

Meine Testfrage dafür ist simpel: Server ausschalten und durchs Haus gehen. Alles, was jetzt nicht mehr geht, aber nach Meinung der Bewohner „immer gehen muss”, liegt auf der falschen Ebene.

Methode 1: ESPHome — die Automation wohnt auf dem Chip

Der erste und gründlichste Weg. Wer mit ESPHome eigene Geräte baut, hat die Wahl, wo die Logik lebt: als Automation in Home Assistant oder als Automation in der YAML-Konfiguration des Geräts selbst. Für Grundfunktionen ist die Antwort eindeutig. Ein Wandtaster, der physisch am GPIO des Controllers hängt, bekommt ein on_press, das direkt das lokale Relais oder die lokale Lichtkomponente toggelt. Kein Netzwerk beteiligt, keine Zentrale gefragt.

Die ESPHome-Doku ist an dieser Stelle erfreulich unmissverständlich. Auf die Frage, ob Automationen ohne Netzwerkverbindung funktionieren, antwortet sie wörtlich: „YES! All automations you define in ESPHome are executed on the microcontroller itself and will continue to work even if the Wi-Fi network is down”. Das ist keine Nebenwirkung, das ist Designziel.

Das Schöne daran: Home Assistant verliert nichts. Der Zustand des Relais wird weiterhin gemeldet, sobald die Verbindung steht, das Dashboard zeigt das Licht korrekt an, und jede HA-Automation darf zusätzlich schalten — abends dimmen, bei Abwesenheit ausschalten, was immer der Kontext hergibt. Der Taster an der Wand aber funktioniert auch dann, wenn WLAN, Broker und Server allesamt schweigen. Ich verdrahte inzwischen jeden ESPHome-Aktor so, dass seine primäre Bedienung lokal ist, und behandle alles von außen als Zusatz.

Methode 2: Zigbee-Binding lässt den Taster direkt mit der Lampe sprechen

Der zweite Weg braucht keine Lötstation. Zigbee hat direktes Gerät-zu-Gerät-Steuern von Haus aus im Protokoll, das Feature heißt Binding. Die Zigbee2MQTT-Doku beschreibt es genau so: Geräte steuern einander direkt, „without the intervention of Zigbee2MQTT”. Der Taster schickt sein Kommando nicht an den Koordinator zur Weiterverarbeitung, sondern über das Mesh an die gebundene Lampe. Server neu gestartet? Zigbee2MQTT im Update? Der Lampe ist das egal.

In der Praxis bindet man selten an eine einzelne Lampe, sondern an eine Zigbee-Gruppe: Badezimmer-Taster an Gruppe „Bad”, und alle drei Spots reagieren gleichzeitig, mit einem einzigen Gruppen-Kommando statt drei Einzelbefehlen. Das entlastet nebenbei das Funknetz. ZHA-Nutzer müssen nicht neidisch werden, Binding geht dort über die Geräteseite genauso.

Zwei ehrliche Einschränkungen. Erstens unterstützt nicht jedes Gerät Binding, das hängt an der Zigbee-Implementierung des Herstellers; IKEA-Geräte sind hier traditionell brav, andere Marken melden gebundene Zustandsänderungen nur teilweise zurück. Zweitens schlafen batteriebetriebene Taster tief und fest — beim Einrichten des Bindings muss man sie aufwecken, sonst schlägt es kommentarlos fehl. Beides steht in der verlinkten Doku, beides ist in zehn Minuten gelöst.

Was sonst noch direkt geht

Z-Wave kann das Gleiche und nennt es Assoziation. Ein Gerät bekommt in einer Assoziationsgruppe das Ziel eingetragen und schickt sein Basic_Set fortan direkt, auch wenn der Controller ausgeschaltet oder defekt ist. Unter Home Assistant richtet man das über die Z-Wave-JS-Geräteseite ein, typischerweise ab Gruppe 2 aufwärts. Die Kommandos sind bewusst schlicht, an, aus, dimmen, mehr nicht. Für Reflexe reicht das exakt.

Wer eine Hue-Bridge im Haus hat, kann ihre Bordmittel als eigene Ebene nutzen: Ein Hue-Dimmer, der direkt an der Bridge angelernt ist, schaltet seine Lampen auch dann, wenn Home Assistant nicht antwortet. Das ist streng genommen nur eine kleinere Zentrale statt keiner, aber es ist eine zweite, unabhängige — und sie hat deutlich seltener Updates.

Shelly-Relais bringen das Prinzip sogar in die Unterputzdose. Der physische Wandschalter hängt elektrisch am Schalteingang des Relais und schaltet lokal auf dem Gerät, WLAN hin oder her. Interessant ist der Umkehrschluss: Der beliebte „Detached Mode”, bei dem der Eingang nur noch Events sendet und der Server das Schalten übernimmt, baut genau die Abhängigkeit wieder ein, um die es hier geht. Manchmal ist das den Komfort wert. Man sollte es nur wissend entscheiden, nicht aus Gewohnheit.

Und Matter? Der Standard sieht Bindings ausdrücklich vor, Geräte sollen einander ohne Controller steuern können. Home Assistant hat erste Binding-Funktionen im Matter-Add-on nachgerüstet, noch rudimentär, und die Geräteunterstützung ist dünn. Beobachten, noch nicht drauf bauen. Die KNX-Fraktion darf an dieser Stelle übrigens milde lächeln: Dort ist Logik in den Geräten seit Jahrzehnten der Normalfall, und der Bus kennt gar keinen zentralen Server, der ausfallen könnte.

Die Ebenen im Vergleich

Die unterste Zeile ist nicht die schlechteste, sie ist für etwas anderes da. Genau das ist der Punkt: Es geht nicht darum, Home Assistant zu entmachten, sondern jede Logik auf die Ebene zu legen, die sie wirklich braucht. „Licht an” braucht keinen Python-Interpreter.

Was bleibt fürs Gehirn übrig?

Alles Interessante. Szenen, die mehrere Gewerke koordinieren. Anwesenheit, Zeitpläne, Energiepreise, Wetter. Benachrichtigungen, Statistik, das Dashboard als Fenster ins Haus. Wer die Reflexe auslagert, degradiert Home Assistant nicht, er macht Home Assistant zuverlässiger und freier zugleich: Der Server darf jetzt das tun, was nur er kann, und niemand hält beim Update die Luft an. Es ist derselbe Gedanke, der lokale Installationen resilienter macht als Cloud-Abhängigkeiten — nur eine Ebene tiefer angewendet, auf den eigenen Server statt auf fremde.

Für alle, die Home Assistant beruflich bei Kunden installieren, ist das mehr als Hygiene. Eine Anlage, deren Grundfunktionen Updates und Neustarts nicht spüren, produziert keine Anrufe um 21 Uhr. Man kann Wartung in einem sauberen, befristeten Fenster fahren, Core aktualisieren, Add-ons neu starten, und der Kunde merkt es schlicht nicht. Bei einer Handvoll eigener Geräte prüft man das per Hand. Bei zwanzig Kundeninstallationen will man den Update-Stand und Zustand aller Anlagen an einem Ort sehen, sonst frisst die Kontrolle die Zeit, die die Architektur gespart hat.

Zum Schluss zurück in die Dusche, wo dieser Post angefangen hat. Das Core-Update läuft, der Server bootet, das Dashboard ist kurz grau. Und das Licht? Das Licht geht an. Weil zwischen Taster und Lampe niemand mehr sitzt, der gerade etwas Besseres zu tun hat.