Eine Lichtautomation entwerfen, die im Alltag verständlich bleibt

Eine automatisch eingeschaltete Lampe ist schnell eingerichtet. Schwieriger ist die Frage, wann sie wieder ausgehen darf. Im Flur kann jemand nur vorbeilaufen, Schuhe anziehen oder mit einer Einkaufstasche stehen bleiben. Ein Bewegungsmelder sieht diese Situationen nicht gleich gut. Gleichzeitig möchte niemand erklären müssen, warum das Licht mitten in einer Handlung erlischt oder nach einem manuellen Ausschalten sofort wieder angeht.

Eine gute Lichtautomation beginnt deshalb mit einer Alltagsbeschreibung. In diesem Beispiel soll eine Flurlampe bei erkannter Bewegung leuchten, wenn automatisches Licht ausdrücklich erlaubt ist. Nach einer ruhigen Phase darf sie wieder ausgehen. Ein manueller Übersteuerungsmodus hält die Lampe bei Bedarf unabhängig vom Sensor an. Das ist ein Entwurf für eine Lernumgebung, keine Beschreibung bereits installierter Geräte im Zuhause von BlackZack.

Das gewünschte Verhalten zuerst aufschreiben

Vor dem Öffnen des Automationseditors werden vier Situationen notiert. Erstens kommt jemand in den Flur, während automatisches Licht erlaubt ist. Zweitens bleibt die Person länger dort. Drittens verlässt sie den Bereich. Viertens möchte sie die Automatik für eine Weile übersteuern. Für jede Situation wird festgelegt, welches Verhalten angenehm wäre und welche Information das System tatsächlich besitzt.

Der Sensor liefert in diesem Beispiel einen Bewegungszustand. Er bestätigt damit keine lückenlose Anwesenheit. Ein Mensch, der still steht oder außerhalb des Erfassungsbereichs sitzt, kann für den Sensor verschwinden. Diese Einschränkung gehört bereits in die Planung. Eine sehr kurze Ausschaltverzögerung kann zwar Laufzeit sparen, aber eine Beleuchtung unbrauchbar machen. Der Wert wird deshalb später anhand mehrerer echter Nutzungssituationen angepasst.

Auch die Helligkeitsentscheidung braucht eine klare Bedeutung. Für den ersten Test verwenden wir einen bewusst gesetzten Helfer, der die Automatik freigibt. Erst wenn das Grundverhalten zuverlässig ist, könnte eine gesonderte Regel diese Freigabe aus einer Helligkeitsmessung oder einem Zeitfenster ableiten. So wird nicht gleichzeitig an Bewegung, Messwertschwelle, Tageszeit und Ausschaltlogik gearbeitet. Fehler bleiben einer kleinen, überschaubaren Funktion zuordenbar.

Einschalten und Ausschalten getrennt betrachten

Zwei kleine Regeln sind häufig leichter zu verstehen als eine große Regel mit vielen verschachtelten Zweigen. Die erste reagiert auf Bewegung und schaltet ein. Die zweite reagiert darauf, dass eine Weile keine Bewegung gemeldet wurde, und prüft vor dem Ausschalten die Übersteuerung. Diese Trennung macht die jeweiligen Absichten sichtbar und erlaubt unterschiedliche Bedingungen für den Beginn und das Ende der Beleuchtung.

Ein oft übersehener Punkt ist, dass eine Einschaltbedingung nicht zwangsläufig auch eine Ausschaltbedingung sein sollte. Wenn ein Helligkeitssensor die eingeschaltete Lampe sieht, wird es nach dem Einschalten hell. Würde die Ausschaltregel nun ebenfalls „nur bei Dunkelheit“ verlangen, könnte sie gerade deshalb nicht mehr laufen. Bedingungen müssen aus der Bedeutung der jeweiligen Aktion entstehen, nicht aus der Gewohnheit, überall dieselbe Prüfung zu kopieren.

Die offizielle Dokumentation zu Auslösern beschreibt zustandsbasierte Ereignisse und Zeitbedingungen. Für unseren Entwurf reicht die Unterscheidung zwischen einem Übergang und einer Dauer: „Es wurde Bewegung erkannt“ ist etwas anderes als „Seit einer bestimmten Zeit ist keine Bewegung mehr gemeldet“. Aus dieser Unterscheidung entstehen zwei klar getrennte Prüffälle.

Ein kleines, ausdrücklich beispielhaftes Regelpaar

Die folgenden Kennungen stehen ausschließlich für eine Testumgebung. Vor einer Verwendung müssen passende Helfer und Geräte vorhanden sein und die Kennungen ersetzt werden. Der erste Helfer erlaubt die automatische Beleuchtung. Der zweite kennzeichnet eine manuelle Übersteuerung. Diese zusätzlichen Zustände sind nur dann sinnvoll, wenn ihre Bedienung auf einer Oberfläche verständlich erklärt wird.

alias: Beispiel Flurlicht einschalten
triggers:
  - trigger: state
    entity_id: binary_sensor.beispiel_flur_bewegung
    to: "on"
conditions:
  - condition: state
    entity_id: input_boolean.beispiel_flur_automatik
    state: "on"
actions:
  - action: light.turn_on
    target:
      entity_id: light.beispiel_flur
mode: single

alias: Beispiel Flurlicht nach Ruhe ausschalten
triggers:
  - trigger: state
    entity_id: binary_sensor.beispiel_flur_bewegung
    to: "off"
    for: "00:03:00"
conditions:
  - condition: state
    entity_id: input_boolean.beispiel_flur_manuell
    state: "off"
actions:
  - action: light.turn_off
    target:
      entity_id: light.beispiel_flur
mode: single

Das Beispiel ist absichtlich klein. Es behandelt noch keinen speziellen Nachtmodus, keine unterschiedlichen Farbtemperaturen und keinen automatischen Ablauf der manuellen Übersteuerung. Diese Beschränkung ist nützlich: Zuerst lässt sich prüfen, ob die beiden grundlegenden Übergänge funktionieren. Weitere Wünsche können danach ergänzt werden, jeweils zusammen mit einer Beschreibung ihrer Wirkung und einer gezielten Probe.

Die manuelle Bedienung als eigenen Ablauf gestalten

Ein Helfer mit dem Namen „manuell“ löst das Bedienproblem noch nicht allein. Es muss einen verständlichen Weg geben, ihn einzuschalten, die Lampe passend zu setzen und später wieder zur Automatik zurückzukehren. Eine Schaltfläche „Licht dauerhaft an“ könnte beide ersten Schritte übernehmen. Eine zweite Aktion „Automatik wieder verwenden“ beendet die Übersteuerung. Beide Aktionen sollten den sichtbaren Zustand aktualisieren.

Dabei entsteht ein wichtiger Randfall: Wird die Übersteuerung beendet, während der Sensor bereits seit längerer Zeit keine Bewegung meldet, tritt nicht unbedingt erneut der erwartete Zustandsübergang auf. Die Aktion zur Rückkehr in die Automatik muss deshalb bewusst entscheiden, was jetzt passieren soll. Sie kann zum Beispiel einen getrennten Prüfablauf starten. Einfach nur den Helfer zurückzusetzen und auf ein zukünftiges Ereignis zu hoffen, wäre eine unvollständige Bedienung.

Auch ein physischer Wandschalter verdient eine eigene Betrachtung. Nicht jede Hardware meldet, ob ein Zustandswechsel durch einen Menschen oder durch eine Automation verursacht wurde. Eine Regel, die aus jedem eingeschalteten Lampenzustand automatisch „manuelle Übersteuerung“ ableitet, könnte ihre eigenen Aktionen missverstehen. Wenn die Ursache nicht zuverlässig bekannt ist, ist eine ausdrückliche Bedienaktion oft verständlicher als eine scheinbar intelligente Vermutung.

Fehlende Sensorwerte verändern die Entscheidung

Ein Bewegungsmelder kann zeitweise keine verwertbare Information liefern. Für die Lichtregel muss entschieden werden, wie dieser Zustand behandelt wird. Das Beispiel reagiert beim Einschalten ausdrücklich auf einen gemeldeten eingeschalteten Zustand und beim Ausschalten auf einen gemeldeten ausgeschalteten Zustand über eine bestimmte Dauer. Es interpretiert einen nicht verfügbaren Zustand nicht als bestätigte Abwesenheit.

Diese Entscheidung bedeutet allerdings nicht, dass bei einem Sensorausfall automatisch jedes Problem gelöst ist. Eine bereits eingeschaltete Lampe könnte anbleiben. Ob das akzeptabel ist, hängt von der Nutzung ab. Im Beispiel wird dieses Verhalten zunächst sichtbar gemacht und manuelle Bedienung angeboten. Eine zusätzliche zeitliche Begrenzung wäre eine eigene Anforderung, die wiederum erklären müsste, was sie bei einer aktiven Übersteuerung oder einem längeren Aufenthalt tun soll.

Bei der Fehlersuche wird außerdem zwischen Sensor, Verbindung und Lampe unterschieden. Der Sensor kann korrekt melden, während der Schaltbefehl die Lampe nicht erreicht. Ebenso kann ein gemeldeter Lampenzustand veraltet sein. Eine brauchbare Diagnoseansicht zeigt deshalb nicht nur „Automation läuft“, sondern ermöglicht einen Blick auf die beteiligten Zustände. Die alltägliche Oberfläche darf dabei weiterhin einfach bleiben.

Neustarts sind ein eigener Testfall

Eine Verzögerung, die auf einer über einen Zeitraum gehaltenen Zustandsbedingung beruht, muss im Zusammenhang mit Neustarts und dem Neuladen von Automationen betrachtet werden. Die Dokumentation weist für entsprechende for-Auslöser darauf hin, dass solche Wartezeiten nicht über diese Vorgänge hinweg erhalten bleiben. Das Verhalten nach einem Neustart darf deshalb nicht aus der normalen Laufzeit abgeleitet werden.

Für ein unkritisches Flurlicht kann ein bewusst akzeptiertes Verhalten ausreichend sein: Nach dem Neustart übernimmt die manuelle Bedienung, bis wieder passende Ereignisse eintreten. Wer einen genau definierten Wiederanlauf benötigt, ergänzt einen eigenen Startablauf. Dieser prüft die aktuellen Zustände und entscheidet anhand ausdrücklich festgelegter Regeln. Auch dabei dürfen unbekannte Zustände nicht ohne Begründung in eine sichere Information umgedeutet werden.

Ein Neustarttest wird mit einer bereits eingeschalteten Lampe, einer ausgeschalteten Lampe und einer aktiven Übersteuerung durchgeführt. Das Ergebnis wird kurz notiert. So entsteht eine Erwartung, die beim nächsten Update erneut überprüft werden kann. Ohne diese Probe fällt ein unpassendes Verhalten häufig erst dann auf, wenn gerade niemand Zeit für eine Untersuchung hat.

Den Automationsmodus aus der Arbeit ableiten

Bei den beiden kurzen Beispielregeln gibt es keine lange Aktionsfolge. Deshalb ist ein einfacher Modus zunächst nachvollziehbar. Anders wäre es bei einem Ablauf, der mehrere Minuten wartet, langsam dimmt oder verschiedene Leuchten nacheinander verändert. Dann muss klar sein, was ein weiteres Ereignis während des laufenden Ablaufs bewirkt.

Die Dokumentation zu Automationsmodi erläutert die verfügbaren Verhaltensweisen. Für die Planung ist die konkrete Frage wichtiger als der Name: Soll ein neuer Anlass ignoriert werden, den bisherigen Ablauf ersetzen, später bearbeitet werden oder gleichzeitig laufen? Mehrere gleichzeitig aktive Ausschaltabläufe können beispielsweise schwer verständliche Ergebnisse erzeugen, wenn sie dieselbe Lampe mit unterschiedlichen Annahmen steuern.

Ein Modus wird daher nicht vorsorglich auf möglichst viel Parallelität gestellt. Stattdessen wird ein kleines Ereignisprotokoll skizziert: Bewegung, kurze Pause, neue Bewegung, manuelle Bedienung. Danach wird überlegt, welche Aktion zu welchem Zeitpunkt noch gültig sein soll. Erst dieses gewünschte Verhalten bestimmt die technische Umsetzung. Eine kurze Skizze verhindert dabei oft eine lange Folge zufälliger Änderungen im Editor.

Mit Nutzungssituationen statt nur mit einem Testknopf prüfen

Ein manuell gestarteter Aktionsblock beweist, dass die Lampe einen Befehl erhalten kann. Er beweist nicht, dass der richtige Auslöser greift oder die Bedingungen im Alltag passen. Für die vollständige Prüfung wird deshalb der tatsächliche Sensor verwendet. Ein Durchgang durch den Flur muss dieselbe Kette auslösen, die später auch von Bewohnern erwartet wird.

Zur Testliste gehören ein kurzer Durchgang, ein längerer Aufenthalt, mehrere Bewegungen kurz hintereinander, eine ausgeschaltete Freigabe und eine aktive Übersteuerung. Zusätzlich wird geprüft, wie die Rückkehr aus der Übersteuerung funktioniert. Zwischen den Proben sollte ausreichend Zeit liegen, damit die Ausgangszustände bekannt sind. Sonst wird das Ergebnis eines früheren Ablaufs leicht einer späteren Handlung zugeschrieben.

Die Anleitung zur Fehlersuche mit Traces zeigt die dafür vorgesehenen Werkzeuge. Für jede unerwartete Reaktion wird zuerst der konkrete Ablauf betrachtet: Was hat ausgelöst, welche Bedingung wurde geprüft, welche Aktion wurde erreicht? Danach wird genau eine Änderung vorgenommen. Dieses Vorgehen ist ruhiger und meist erfolgreicher, als die gesamte Automation nach jeder Überraschung neu zu schreiben.

Wann die Regel wirklich fertig ist

Eine Lichtautomation ist nicht allein deshalb fertig, weil sie einmal korrekt geschaltet hat. Fertig bedeutet hier, dass ihre normalen Abläufe verständlich sind, ihre Grenzen bekannt bleiben und die manuelle Bedienung erreichbar ist. Andere Bewohner sollten erkennen können, ob die Automatik aktiv ist und wie sie zu einem gewünschten Zustand zurückkehren.

Die erste Version darf dabei bewusst einfach bleiben. Erst aus wiederkehrenden Beobachtungen entstehen sinnvolle Erweiterungen, etwa eine andere Helligkeit in einer klar definierten Situation. Jeder zusätzliche Zweig erhöht die Zahl möglicher Wechselwirkungen. Eine Erweiterung verdient deshalb denselben kleinen Ablauf wie die Grundregel: Wunsch beschreiben, benötigte Information prüfen, Verhalten umsetzen und mit echten Situationen testen. So wächst die Beleuchtung aus dem Alltag heraus und bleibt auch nach mehreren Änderungen noch erklärbar.