Auslöser, Bedingungen und Aktionen gezielt kombinieren

Eine kleine Automation lässt sich oft in einem Satz beschreiben: Wenn eine Tür geöffnet wird, soll ein Licht angehen. Schwierigkeiten entstehen erst, wenn der Satz ergänzt wird. Das Licht soll vielleicht nur am Abend reagieren, eine Pause berücksichtigen und nach einer manuellen Änderung nicht sofort wieder eingeschaltet werden. Wer alle Ergänzungen direkt in eine lange Regel schreibt, verliert schnell den Überblick darüber, welcher Teil eigentlich für welches Verhalten verantwortlich ist. Eine bewusste Trennung macht die Idee überprüfbar, bevor zusätzliche Geräte beteiligt werden.

Für das folgende Beispiel dient eine erfundene Schrankbeleuchtung. Ein Kontakt meldet die Türstellung, eine Lampe beleuchtet das Innere und ein Helfer erlaubt das vorübergehende Pausieren. Die Namen sind Platzhalter; sie beschreiben keine Geräte oder Gewohnheiten aus meinem Zuhause. Das Beispiel eignet sich gerade wegen seines kleinen Umfangs: Jede Entscheidung kann einzeln beobachtet werden. Es geht zunächst ausschließlich um das Einschalten. Das Ausschalten wird später als eigene Anforderung betrachtet, damit beide Richtungen nicht unbemerkt unterschiedliche Annahmen bekommen.

Den Anlass präzise beschreiben

Der Auslöser beantwortet, wann die Automation überhaupt eine Entscheidung beginnen soll. Eine Türöffnung ist ein Ereignis im Verlauf: Vorher war die Tür geschlossen, anschließend ist sie offen. Die offene Tür als dauerhafter Zustand ist etwas anderes. Diese Unterscheidung hilft bei der Frage, warum eine nachträglich eingeschaltete Automation nicht zwingend sofort reagiert. Der gewünschte Anlass liegt möglicherweise bereits zurück. Wer eine automatische Nachholung erwartet, muss diesen zusätzlichen Anlass ausdrücklich in den Entwurf aufnehmen.

Die aktuelle Home-Assistant-Dokumentation beschreibt neben allgemeinen Zustandsauslösern auch spezifischere Auslöser für passende Geräte und Messungen. Entscheidend bleibt die fachliche Auswahl: Soll eine Änderung, ein Zeitpunkt oder ein anderes Ereignis die Entscheidung anstoßen? Die konkrete Auswahl im Editor hängt von der vorhandenen Integration ab. Für ein Beispiel in YAML lässt sich ein gewöhnlicher Zustandswechsel besonders transparent darstellen. Die offizielle Übersicht zu Auslösern erklärt die verfügbaren Formen und ihre Konfiguration.

Im Arbeitsblatt für die Schrankbeleuchtung steht deshalb zuerst nur: „Die Tür wechselt von geschlossen zu offen.“ Eine Helligkeitsmessung und die Pause werden hier noch nicht ergänzt. Dadurch lässt sich zunächst prüfen, ob genau dieser Wechsel zuverlässig sichtbar ist. Ein falsch herum eingebauter Kontakt oder eine überraschende Zustandsbezeichnung fällt dann auf, bevor eine zusätzliche Bedingung das Ergebnis verdeckt. Die Beobachtung des Rohsignals spart später viel Rätselarbeit, weil die grundlegende Bedeutung bereits geklärt ist.

Eine Bedingung ist eine Entscheidung zum Prüfzeitpunkt

Nach dem Anlass folgt die Frage, ob die Wirkung jetzt erlaubt ist. Im Beispiel soll der Helfer für die Pause ausgeschaltet sein. Diese Regel gehört zur Erlaubnis, nicht zur Beschreibung der Türöffnung. Sie kann den begonnenen Ablauf ablehnen. Daraus folgt eine wichtige Produktentscheidung: Wenn die Pause später endet und die Tür weiterhin offen steht, soll das Licht dann nachträglich angehen? Beide Antworten sind denkbar, aber sie führen zu unterschiedlichen Auslösern und unterschiedlichen Erwartungen.

Für den ersten Entwurf lautet die Antwort nein. Wer die Pause beendet, stellt nur die automatische Reaktion für die nächste Türöffnung wieder her. Das ist einfach zu erklären und verhindert eine unerwartete unmittelbare Schaltung. Eine andere Familie könnte gerade die sofortige Angleichung wünschen. Dann müsste auch das Ende der Pause eine erneute Prüfung anstoßen. Die zusätzliche Funktion wäre kein bloßer technischer Feinschliff, sondern eine bewusst geänderte Bedienregel. Sie gehört entsprechend in die Beschreibung und in den Testplan.

Bedingungen sollten außerdem so benannt werden, dass ihre Ablehnung verständlich bleibt. „Automatik pausiert“ erklärt ein ausbleibendes Licht besser als eine unbenannte Kombination mehrerer Werte. Wenn später eine weitere Voraussetzung hinzukommt, wird sie separat dokumentiert. So kann bei einer Beschwerde gezielt gefragt werden, welche Voraussetzung zum Zeitpunkt der Türöffnung galt. Ein Blick auf den aktuellen Zustand reicht nicht immer: Zwischen der ursprünglichen Entscheidung und der Untersuchung können andere Personen Einstellungen verändert haben.

Die Wirkung klein und eindeutig halten

Eine Aktion beschreibt die beabsichtigte Änderung. Im Beispiel wird die Lampe auf eingeschaltet gesetzt. Eine solche Zielvorgabe ist für diesen Anlass verständlicher als ein Umschalten: Zwei versehentlich doppelte Einschaltanforderungen führen weiterhin zum selben Ziel. Zweimaliges Umschalten könnte das Licht dagegen wieder ausschalten. Das ist eine Entwurfsüberlegung für genau diesen Fall, keine Behauptung, dass alle Geräte jede Wiederholung gleichermaßen verarbeiten. Die konkrete Integration muss weiterhin am echten Gerät geprüft werden.

Der folgende Ausschnitt ist ein vollständiger kleiner Entwurf für den YAML-Editor einer einzelnen Automation. Die drei Entitätsnamen müssen an eine eigene Testumgebung angepasst werden. Der Helfer muss dort zuvor vorhanden sein. Der Ausschnitt erzeugt weder den Kontakt noch die Lampe noch den Helfer. Die ausdrücklich angegebenen Zustände vermeiden außerdem, dass eine beliebige andere Aktualisierung bereits als die geplante Türöffnung gelesen wird. Vor dem Aktivieren wird geprüft, ob der verwendete Kontakt tatsächlich die Zustände off und on passend meldet.

alias: "Beispiel: Schrank bei Türöffnung beleuchten"
triggers:
  - trigger: state
    entity_id: binary_sensor.beispiel_schranktuer
    from: "off"
    to: "on"
conditions:
  - condition: state
    entity_id: input_boolean.beispiel_schrank_pause
    state: "off"
actions:
  - action: light.turn_on
    target:
      entity_id: light.beispiel_schrank
mode: single

Der Entwurf enthält absichtlich keine Zeitverzögerung. Dadurch lässt sich die unmittelbare Entscheidung gut beobachten. Er enthält auch keine automatische Abschaltung, weil deren gewünschter Anlass noch nicht definiert wurde. Diese Begrenzung wird bei der Übergabe ausgesprochen: Das Beispiel demonstriert die Einschaltseite und ist noch keine vollständige Beleuchtungssteuerung. Eine klar begrenzte erste Fassung ist leichter zu testen als eine vermeintlich fertige Lösung, deren ergänzende Regeln nur zufällig entstanden sind.

Mehrere Anlässe brauchen eine gemeinsame Bedeutung

Für eine zweite Fassung könnte zusätzlich ein Taster das Einschalten anfordern. Dann stellt sich zuerst eine fachliche Frage: Soll die Pause auch für den Taster gelten? Wenn die Pause nur automatische Türreaktionen unterbindet, wäre eine gemeinsame pauschale Bedingung falsch. Der Taster ist dann eine ausdrückliche manuelle Anforderung und bekommt einen eigenen Weg. Soll die Pause dagegen alle Schaltungen verhindern, kann eine gemeinsame Erlaubnis passen. Die Entscheidung wird aus dem Zweck der Pause abgeleitet, nicht aus der bequemsten Verschachtelung.

Home Assistant unterstützt mehrere Auslöser und Kennungen, über die sich der Anlass später unterscheiden lässt. Für eine kleine Regel kann das hilfreich sein. Eine wachsende Sammlung völlig unterschiedlicher Aufgaben wird dadurch aber nicht automatisch übersichtlicher. Im Beispiel wäre eine getrennte Tasterautomation oft leichter zu erklären. Die beiden Abläufe könnten dieselbe eindeutig beschriebene Aktion verwenden, ohne ihre unterschiedlichen Voraussetzungen zu vermischen. Eine gemeinsame Datei ist kein Qualitätsmerkmal, wenn die Bedeutung ihrer Verzweigungen nur noch eine Person kennt.

Für die Dokumentation hilft ein kurzer Satz pro Weg. „Türöffnung schaltet ein, wenn die Automatik nicht pausiert.“ „Taster schaltet auf ausdrücklichen Wunsch ein.“ Bereits diese beiden Sätze zeigen, warum eine einzige globale Pause möglicherweise nicht passt. Werden später beide Wege geändert, lässt sich ihre gemeinsame Wirkung weiterhin getrennt von ihren unterschiedlichen Erlaubnissen betrachten. Damit bleibt der Entwurf auch nach mehreren Erweiterungen lesbar, ohne alle Einzelheiten bei jeder Änderung neu herleiten zu müssen.

Fehlende Signale als eigenen Testfall behandeln

Ein nicht erreichbarer Kontakt liefert keine verlässliche Türinformation. Im Beispiel wird daraus nicht automatisch eine Öffnung abgeleitet. Das ist eine bewusste konservative Entscheidung für die Einschaltregel. Nach der Wiederverbindung kann der Kontakt allerdings bereits eine offene Tür melden, ohne den ausdrücklich verlangten Wechsel von geschlossen zu offen zu liefern. Wenn die Steuerung diesen Fall angleichen soll, braucht sie eine ergänzende, separat geprüfte Regel. Die ursprüngliche Automation erfüllt nur den enger formulierten Auftrag.

Auch eine nicht erreichbare Lampe verdient einen eigenen Test. Die Oberfläche kann einen Ausführungsversuch zeigen, während die erwartete Helligkeit ausbleibt. Für die Untersuchung werden deshalb Entscheidung und sichtbare Gerätewirkung getrennt festgehalten. Ein zusätzlicher Wiederholungsmechanismus wird nicht allein aufgrund dieses Einzelfalls eingebaut. Zuerst wird untersucht, ob die Verbindung grundsätzlich zuverlässig ist und welche Rückmeldung die Integration tatsächlich anbietet. Sonst kann eine Wiederholungsschleife einen Verbindungsfehler verdecken, ohne den Alltag nachvollziehbarer zu machen.

Den Ablauf mit einer kleinen Ergebnistabelle prüfen

Eine erste Testreihe benötigt nur wenige Zustände. Bei geschlossener Tür und ausgeschalteter Pause wird geöffnet: Das Licht soll angehen. Danach wird die Pause eingeschaltet und derselbe Wechsel wiederholt: Das Licht soll unverändert bleiben. Anschließend wird bei weiterhin offener Tür die Pause beendet: Nach dem festgelegten ersten Entwurf geschieht noch nichts. Erst das erneute Schließen und Öffnen erzeugt den nächsten vorgesehenen Anlass. Gerade der dritte Fall prüft eine leicht übersehene Erwartung.

Die Ergebnisse werden mit Zeitpunkt, Ausgangszustand und beobachteter Wirkung notiert. Ein bloßes „funktioniert“ reicht für spätere Änderungen kaum aus. Zusätzlich wird ein manueller Aktionsaufruf getrennt erprobt. Er beantwortet, ob die Lampe grundsätzlich angesprochen werden kann, beweist aber nicht den korrekten Weg über den Türkontakt und die Bedingung. Wer beide Prüfungen verwechselt, kann eine fehlerhafte Auslöserkonfiguration übersehen, obwohl der einfachere Lampentest erfolgreich aussieht.

Nach jeder Erweiterung wird dieselbe kurze Testreihe erneut ausgeführt. Eine neue Helligkeitsbedingung darf etwa nicht versehentlich die Bedeutung der Pause verändern. Ein zusätzlicher Taster darf keine doppelte Umschaltlogik einführen. Die festgehaltenen Erwartungen schützen damit die ursprüngliche Bedienidee. Sie machen außerdem sichtbar, wann eine Änderung tatsächlich eine neue Anforderung erfüllt und wann sie nur einen einzelnen beobachteten Fehler mit einer weiteren Ausnahme überdeckt.

Ein weiterer Durchlauf erfolgt nach einem kontrollierten Neustart der Testumgebung. Dabei wird nicht nur nach Fehlern gesucht, sondern auch beobachtet, welche Ausgangszustände wiederhergestellt werden. Eine offen gebliebene Tür und eine weiterhin aktive Pause bilden einen anderen Startpunkt als der gewöhnliche Versuch mit geschlossener Tür. Die erwartete Reaktion wird deshalb vor dem Neustart aufgeschrieben und anschließend verglichen.

Die Abschaltung als nächste bewusste Entscheidung

Erst nach der geprüften Einschaltseite wird das Ausschalten geplant. Soll die Türschließung sofort abschalten, eine kurze Wartezeit beginnen oder eine manuelle Nutzung respektieren? Die Antwort hängt vom gewünschten Gebrauch ab. Eine Wartezeit bringt zusätzliche Fragen bei erneutem Öffnen mit sich; dafür wird der Automationsmodus wichtig. Diese Fragen verdienen einen eigenen Entwurf, statt als beiläufige Ergänzung in den bereits funktionierenden Einschaltweg zu geraten.

Die Schrankbeleuchtung zeigt damit eine übertragbare Arbeitsweise: Anlass, Erlaubnis und Wirkung werden nacheinander formuliert und anschließend als vollständiger Ablauf geprüft. Das Ergebnis ist keine besonders lange Konfiguration. Es ist eine kleine, verständliche Vereinbarung darüber, wann das Zuhause reagieren soll. Wenn die Vereinbarung später geändert wird, sind die betroffenen Entscheidungen sichtbar. Genau diese Nachvollziehbarkeit macht eine Automation auf Dauer leichter zu pflegen als eine Sammlung von Bedingungen, deren ursprünglicher Zweck längst vergessen wurde.