Ein Preset schaltet kein Licht ein

Am 3D-Drucker hängt eine LED-Statusleiste. 53 Pixel, vier Segmente: ein Balken für den Druckfortschritt, ein Balken für die Betttemperatur, ein Farbblock in der Mitte, ein Effektstück am Ende. Die Farbcodierung ist bewusst eindeutig — Cyan auf Magenta heißt „druckt”, Rot ist ausschließlich Fehler, damit ein Blick aus dem Türrahmen reicht.

An diesem Tag druckte der Drucker. Der Status stand sauber auf printing, der Fortschritt bei 47 Prozent, und die Automation hatte korrekt das Druck-Preset ausgewählt.

Der Streifen blieb dunkel.

Der falsche Verdacht zuerst

Mein erster Griff ging zu einer alten Bekannten. Ende August hatte ich in dieselbe Automation einen Schutzmechanismus eingebaut, weil ein Schalter, der eigentlich den Drucker abbildet, dauerhaft off meldete und bei jeder Wiederverbindung kurz flackerte. Dieser Schalter triggerte damals einen Ausschalt-Zweig mitten im laufenden Druck. Der Schutz ist eine Zusatzbedingung: Ausschalten nur, wenn der Druckstatus nicht printing ist.

Naheliegender Verdacht also: Der Schutz greift nicht, der Ausschalt-Zweig hat wieder zugeschlagen.

Nachgesehen — und der Verdacht war falsch. Der fragliche Schalter stand diesmal auf on, nicht auf dem üblichen Dauer-off. Der Ausschalt-Zweig kann in dieser Konstellation gar nicht gefeuert haben, und in der History fand sich auch kein entsprechender Aufruf. Der Schutzmechanismus von August war nachweislich unschuldig.

Das gehört hier hin, weil es genau die Falle ist, in die man beim Debuggen tappt: Man hat einen bekannten Fehler in der Nähe, der ähnlich aussieht, und nimmt ihn für die Erklärung.

Was tatsächlich fehlte

Also der langweilige Weg: Zeile für Zeile durch die Zweige, die während eines Drucks aktiv werden. Davon gibt es drei — den direkten Übergang nach printing, den Sammelzweig für Fortschritt und Temperaturen, und den Zweig, der nach einem Neustart den aktuellen Zustand wiederherstellt.

Alle drei taten dasselbe: Preset auswählen, Intensität setzen. Fertig.

Und da war das Loch. In keinem der drei Zweige stand ein Befehl, der das Licht einschaltet.

Das funktioniert genau so lange gut, wie der Streifen sowieso an ist. War er vorher aus — weil der Drucker im Standby stand, weil das System neu gestartet wurde, weil irgendwann jemand manuell ausgeschaltet hat — dann bleibt er aus. Die Automation wählt brav ein Preset für einen Streifen, der nicht leuchtet, und setzt eine Helligkeit, die niemand sieht. Alle Protokolle melden Erfolg. Alles hat funktioniert. Nur eben unsichtbar.

Der Kern des Denkfehlers steckt im Wort „Preset”. Ein Preset ist eine Beschreibung, kein Befehl. Es sagt: So sieht es aus, wenn es an ist. Farben, Effekt, Segmentaufteilung, Geschwindigkeit. Es sagt nichts darüber, ob es an ist. Ein Preset auswählen ist wie die Kleidung für morgen rauszulegen — es zieht sie niemandem an.

Der Fix war unspektakulär: In allen drei druckaktiven Zweigen ein explizites Einschalten des Masters, vor der Preset-Auswahl. Die Reihenfolge ist kein Zufall — erst an, dann anziehen.

Nebenbemerkung, weil es oft für einen Fehler gehalten wird: Die Preset-Auswahl steht während eines Drucks häufig auf unknown. Das ist normal. Die Automation schreibt laufend die Intensität für den Fortschrittsbalken, damit weicht der Live-Zustand vom gespeicherten Preset ab — und das System sagt ehrlich „das ist keins der gespeicherten mehr”.

Und dann, am selben Tag, noch einmal

Ein paar Stunden später habe ich die Wohnzimmer-Automation erweitert, die bei Bewegung die indirekte Beleuchtung hochfährt: Deckenwolke, Regal, der große Streifen. Neu dazu kamen die Vitrinen.

Der Plan war simpel: Bewegung erkannt, Vitrinen mit einem bestimmten Feuer-Preset einschalten. Bewegung weg, Vitrinen aus.

Und beim Schreiben der Aktion stand ich vor derselben Klippe. Die naheliegende Formulierung wäre gewesen: Preset auswählen, fertig. Exakt derselbe Bug — nur im Wohnzimmer statt am Drucker, und dort hätte ihn abends jemand gesehen.

Weil der Ender-Fall noch frisch war, habe ich in beiden Einschalt-Zweigen, Tag wie Nacht, jeweils ein explizites Einschalten vorangestellt. Derselbe Fix, diesmal präventiv.

Der zweite Stolperstein: der Name, der lügt

Beim Ausschalt-Zweig lauerte direkt der nächste. Die Vitrinenbeleuchtung ist ein großes System — fast neunhundert LEDs auf dreizehn Segmenten. Und für so ein Gerät gibt es in Home Assistant mehr als eine Entity: eine, die exakt so heißt wie das Gerät, und eine zweite mit einem Zusatz im Namen.

Die naheliegende Annahme — die mit dem schlichten Namen ist „der ganze Streifen” — ist falsch. Die ist nur Segment null. Der eigentliche Master ist die mit dem Zusatz. Erkennbar daran, dass er als einzige Eigenschaft Helligkeit anbietet und keine Farbe: Er hat keine eigene, er skaliert nur, was in den Segmenten steht.

Der Ausschalt-Zweig zeigte auf die falsche von beiden. Das Ergebnis wäre gewesen: Bewegung weg, ein Dreizehntel des Systems geht aus, der Rest brennt weiter. Und weil der Rest brennt, fällt niemandem auf, dass überhaupt etwas geschaltet hat. Auf _haupt korrigiert, Konfiguration geprüft, neu geladen.

Dieselbe Falle ist mir später noch bei zwei weiteren Geräten im selben Raum begegnet. Es ist kein Einzelfall, es ist das Muster dieser Integration bei Mehr-Segment-Geräten.

Zwei Merksätze

Erstens: Ein Preset beschreibt, wie etwas aussieht — es schaltet nichts ein. Wenn eine Automation auf einen Zustand reagiert, der auch nach einem Neustart oder aus dem Ruhezustand heraus eintreten kann, muss sie das Einschalten explizit hinschreiben. Nicht annehmen, dass der Ausgangszustand stimmt. Automationen, die nur Deltas beschreiben, haben nach einem Neustart keine Meinung zur Gegenwart.

Zweitens: Bei Mehr-Segment-Geräten immer nachsehen, welche Entity wirklich der Master ist. Der bequemste Name ist selten der richtige.

Und der Meta-Merksatz, der mich den größten Teil der Zeit gekostet hat: Ein bekannter Fehler in der Nähe ist ein Verdächtiger, keine Erklärung. Ich habe den August-Schutz für den Täter gehalten. Er stand nur zufällig am Tatort herum.