Zustand führen für Geräte, die keinen melden

Der Ausgangspunkt

In meiner Wohnung hängen 129 Geräte aus zehn Hersteller-Ökosystemen an Home Assistant; allein die Beleuchtung verteilt sich auf fünf Anbindungswege. Bei vier dieser fünf Wege meldet jedes Gerät seinen Zustand selbst zurück. Beim fünften nicht: Zwölf Govee-Leuchten lassen sich über govee2mqtt zwar ein- und ausschalten, aber ein verlässliches Zwei-Wege-Feedback gibt es nicht. Home Assistant weiß also nicht, ob sie gerade brennen.

Das ist kein Randfall dieser einen Marke. Es betrifft jedes Gerät, das über eine Cloud-Schnittstelle, einen Infrarot-Sender oder eine nachgerüstete Brücke angesprochen wird: Der Befehl geht hinaus, aber nichts kommt zurück.

Warum das eine Szene kaputt macht

Solange man nur einschaltet, ist fehlender Zustand egal. Er wird zum Problem, sobald eine Szene aufräumen soll. Meine Szene „Gute Nacht“ soll das Licht ausmachen, das die Szene „Nachtlicht“ vorher angemacht hat. Ohne Zustandswissen bleiben zwei Möglichkeiten, und beide sind schlecht:

• Immer alle zwölf abschalten. Funktioniert, erzeugt aber bei jedem Aufruf zwölf Befehle, von denen die meisten ins Leere gehen. Bei Cloud-Anbindungen heißt das: zwölf Anfragen, Wartezeit, und ein Aufräumvorgang, der länger dauert als die Szene selbst.
• Gar nichts abschalten, was man nicht kennt. Lampen, die anderswo eingeschaltet wurden, brennen weiter. Die Szene tut dann nicht das, was ihr Name verspricht.

Die Lösung: das System führt selbst Buch

Für jede der zwölf Leuchten gibt es einen eigenen Merker – in Home Assistant ein input_boolean, in jedem anderen System eine Variable. Der Ablauf ist denkbar einfach:

1. Schaltet „Nachtlicht“ eine Lampe ein, wird im selben Schritt ihr Merker gesetzt.
2. „Gute Nacht“ schaltet gezielt nur die Lampen aus, deren Merker gesetzt ist.
3. Danach wird der Merker wieder geleert.

Das Muster heißt anderswo Schattenzustand oder optimistic state. Der Kern ist immer derselbe: Wenn die Wirklichkeit nicht antwortet, führt man ein Protokoll über das, was man ihr aufgetragen hat – und behandelt dieses Protokoll ausdrücklich als das, was es ist. Es ist nicht der Zustand der Lampe. Es ist der Zustand meines Wissens über die Lampe.

Der Tausch, den das macht

Diese Unterscheidung ist nicht akademisch, sie ist die ganze Einschränkung der Methode:

Die zweite Zeile ist der Preis. Der Merker weiß nur von dem, was durch ihn hindurchgelaufen ist. Wird eine Lampe an ihm vorbei geschaltet, ist sein Protokoll falsch – und zwar leise, ohne Fehlermeldung.

Die Voraussetzung, ohne die es nicht funktioniert

Damit die zweite Zeile kein Alltagsfall wird, muss jeder Schaltweg durch dasselbe System laufen. Bei mir heißt das: Hinter jedem physischen Schalter liegt eine Automatisierung, die den Merker mitführt. Apple Home läuft über Homebridge durch dieselbe Logik. Die Hersteller-Apps werden bewusst nicht benutzt.

Wer diese Bedingung nicht herstellen kann – etwa weil Mitbewohner die Hersteller-App verwenden oder ein Gerät auch einen echten Netzschalter hat –, ist mit der stumpfen Variante besser bedient. Sie ist verschwenderisch, aber sie hat keine unsichtbare Vorbedingung. Das ist bei einer Zustandsverwaltung mehr wert, als es klingt: Ein System, das seine eigene Voraussetzung verschweigt, liegt genau dann falsch, wenn man sich auf es verlässt.

Was allgemein daraus folgt

Die Frage ist bei jeder Integration dieselbe und lohnt sich, bevor man anfängt: Antwortet das Gerät, oder nehme ich nur an, dass es gehorcht hat? Wenn es antwortet, ist jede zusätzliche Buchführung überflüssig und wird irgendwann falsch. Wenn es nicht antwortet, ist die Buchführung unvermeidlich – dann muss man sie führen und gleichzeitig aufschreiben, wovon sie abhängt.