Automationsmodi: single, restart, queued und parallel verstehen

Eine Automation kann im Einzelversuch vollkommen richtig wirken und bei zwei schnellen Auslösern trotzdem enttäuschen. Das Licht geht zu früh aus, eine Meldung erscheint verspätet oder eine Aktion wird mehrfach ausgeführt. Der entscheidende Unterschied ist häufig nicht das Gerät, sondern die Behandlung eines weiteren Aufrufs während eines laufenden Ablaufs. Sobald eine Wartezeit beteiligt ist, wird diese Frage sichtbar. Doch auch eine langsame Geräteantwort kann zwei scheinbar getrennte Bedienungen zeitlich überlappen lassen.

Für die Auswahl eines Modus ist deshalb zunächst ein Satz hilfreich: Was soll die zweite Anforderung bedeuten? „Noch einmal genauso“, „die neueste ersetzt die alte“, „bitte später bearbeiten“ und „währenddessen ignorieren“ sind verschiedene Aufträge. Keine dieser Antworten ist grundsätzlich die beste. Die passende Antwort ergibt sich aus der gewünschten Bedienung. Dieser Artikel entwickelt dafür eine erfundene zeitlich begrenzte Beleuchtung. Die Beispiele enthalten keine tatsächlichen Entitätsnamen oder Abläufe eines privaten Haushalts und müssen vor einer Übernahme angepasst werden.

Die vier Möglichkeiten knapp einordnen

Home Assistant bietet vier Automationsmodi. single startet während eines laufenden Durchgangs keinen weiteren. restart beendet den bisherigen Durchgang und beginnt einen neuen, sofern die Bedingungen erfüllt sind. queued führt angenommene Durchgänge nacheinander in ihrer Reihenfolge aus; die Bedingungen für die Aufnahme werden beim Auslösen geprüft. parallel lässt getrennte Durchgänge gleichzeitig laufen. Für Warteschlange und Parallelbetrieb begrenzt max die Zahl der laufenden beziehungsweise wartenden Durchgänge. Die aktuelle Modusreferenz beschreibt diese Regeln und die Meldungen bei überschrittenen Grenzen.

Diese kurze Einordnung beantwortet noch nicht, was im Zuhause passieren soll. Dazu muss der Ablauf zeitlich betrachtet werden. Eine Liste von Aktionen verschweigt leicht, dass zwischen zwei Zeilen Sekunden oder Minuten vergehen können. Während dieser Zeit können andere Personen einen Taster bedienen oder andere Automationen dasselbe Gerät verändern. Ein Modus regelt nur die Durchgänge der betreffenden Automation. Er ist keine allgemeine Vereinbarung zwischen sämtlichen Regeln, die zufällig auf dieselbe Lampe zugreifen.

Ein konkretes Zeitversprechen formulieren

Im Beispiel soll ein Taster eine Arbeitsleuchte für eine kurze Demonstrationsdauer einschalten. Die Dauer beträgt zehn Sekunden, damit der Test nicht unnötig lange dauert. Für den späteren echten Einsatz könnte ein anderer Wert sinnvoll sein. Noch wichtiger als die Zahl ist ihr Bezugspunkt: Zehn Sekunden nach dem ersten Tastendruck und zehn Sekunden nach dem letzten Tastendruck sind unterschiedliche Bedienungen. Beide klingen zunächst nach „kurz einschalten“, führen aber bei wiederholter Betätigung zu einem anderen Ergebnis.

Der Entwurf entscheidet sich für den letzten Tastendruck. Eine Person, die nach sechs Sekunden erneut drückt, soll weitere zehn Sekunden Licht bekommen. Der frühere Abschaltauftrag darf dann nicht nach insgesamt zehn Sekunden dazwischenfunken. Diese Forderung wird zuerst auf Papier festgehalten. Erst danach wird der Modus gewählt. So bleibt er eine Umsetzung der gewünschten Zeitregel und wird nicht zu einem zufällig übernommenen Wert aus einer fremden Beispielkonfiguration.

Für diesen begrenzten Ablauf passt ein Neustart des Durchgangs: Die Leuchte wird eingeschaltet, die Demonstrationszeit beginnt neu und anschließend erfolgt die Abschaltung. Dass das erneute Einschalten hier denselben Zielzustand anfordert, ist beabsichtigt. Bei einem Umschaltbefehl wäre die Bedeutung anders. Die Überlegung lässt sich deshalb nicht unverändert auf beliebige Aktionsfolgen übertragen. Wer den Modus kopiert, muss weiterhin prüfen, was die wiederholten Aktionen vor der Wartezeit tatsächlich bewirken.

Einen kleinen Versuchsaufbau verwenden

Der folgende Entwurf reagiert auf ein eigens benanntes Testereignis. Er soll zunächst mit einer ungefährlichen Testlampe verwendet werden. Das Ereignis wird kontrolliert ausgelöst; es ist kein universeller Name für einen realen Wandtaster. Für die spätere Verbindung mit einem tatsächlichen Gerät wird der passende Auslöser aus dessen Integration gewählt. Der Aufbau trennt damit die Frage nach dem Modus von möglichen Eigenheiten eines konkreten Tasters oder seiner Funkverbindung.

alias: "Beispiel: kurze Arbeitsbeleuchtung verlängern"
triggers:
  - trigger: event
    event_type: beispiel_arbeitslicht_anforderung
conditions: []
actions:
  - action: light.turn_on
    target:
      entity_id: light.beispiel_arbeitsleuchte
  - delay: "00:00:10"
  - action: light.turn_off
    target:
      entity_id: light.beispiel_arbeitsleuchte
mode: restart

Der Ausschnitt zeigt eine einzelne Automation für den YAML-Editor. Er ist kein Ersatz für eine vollständige Raumbeleuchtung und berücksichtigt keine manuelle Übernahme. Diese Grenze ist relevant: Schaltet eine Person während der Wartezeit dieselbe Lampe aus einem anderen Grund dauerhaft ein, kann die geplante Abschaltung weiterhin unerwünscht sein. Eine solche Übernahme braucht eine eigene Anforderung und eine passende Prüfung. Der Modus allein erkennt nicht, warum ein anderer Weg dasselbe Gerät verändert hat.

Den zweiten Aufruf auf einer Zeitlinie prüfen

Im ersten Versuch wird das Ereignis einmal ausgelöst. Die Leuchte soll angehen und ungefähr nach der Demonstrationsdauer wieder ausgehen. Damit ist lediglich der einfache Durchgang geprüft. Im zweiten Versuch folgt nach sechs Sekunden ein weiteres Ereignis. Jetzt wird besonders der ursprüngliche Abschaltzeitpunkt beobachtet: Nach zehn Sekunden seit dem ersten Ereignis muss die Leuchte weiterhin eingeschaltet sein. Erst nach der neuen Wartezeit soll die Abschaltung erfolgen. Die Zeitangaben sind Testvorgaben, keine Messwerte eines bereits ausgeführten Haushaltsversuchs.

Im dritten Versuch folgen mehrere Ereignisse mit kurzen Abständen. Das Ende der Beleuchtung soll sich immer auf die letzte angenommene Anforderung beziehen. Dabei wird auch beobachtet, ob das erneute Einschalten sichtbare Nebenwirkungen hat. Manche Geräte oder Einstellungen können etwa einen unerwünschten Helligkeitssprung zeigen. Ein bestandener Test der zeitlichen Logik sagt noch nichts über diese Gerätewirkung aus. Deshalb werden Verlauf und sichtbares Verhalten getrennt notiert.

Für die Notiz reichen Ereigniszeit, erwarteter Abschaltzeitpunkt und beobachtete Reaktion. Eine solche Tabelle macht ein Problem wesentlich konkreter als „restart ist unzuverlässig“. Wenn der beobachtete Ablauf abweicht, lässt sich prüfen, ob ein Ereignis fehlte, ein anderer Ablauf eingriff oder die Lampe verzögert reagierte. Erst nach dieser Zuordnung wird die Konfiguration geändert. Andernfalls kann ein Moduswechsel einen Fehler scheinbar beseitigen, obwohl er lediglich das ursprüngliche Zeitversprechen verändert.

Wann das Ignorieren weiterer Aufrufe passt

Für einen anderen Zweck könnte das erste Ereignis einen festen kurzen Hinweis auslösen. Weitere Meldungen während dieses Hinweises sollen keine zusätzliche Wirkung haben. Dann wäre ein weiterer Durchgang unerwünscht, und single könnte zur gewählten Bedienregel passen. Entscheidend ist die ausdrückliche Aussage, dass zwischenzeitliche Anforderungen verfallen dürfen. Bei einer bloßen Statusanzeige ist das vielleicht angemessen; bei einem Auftrag, den eine Person zuverlässig erledigt erwartet, wäre dieselbe Entscheidung möglicherweise überraschend.

Im Beleuchtungsbeispiel würde ein ignorierter zweiter Tastendruck das Versprechen „ab dem letzten Tastendruck“ verletzen. Genau deshalb ist der Modus dort unpassend, obwohl der erste Test weiterhin richtig aussieht. Dieser Vergleich ist eine nützliche Methode für andere Automationen: Der Testfall mit nur einem Ereignis wird durch mindestens einen überlappenden Aufruf ergänzt. Erst dieser zweite Fall zeigt, ob die gewählte Behandlung zusätzlicher Wünsche mit der Erklärung für die Nutzer übereinstimmt.

Eine Warteschlange braucht noch sinnvolle Aufträge

Eine Warteschlange eignet sich für Aufgaben, die tatsächlich nacheinander bearbeitet werden sollen. Das bedeutet jedoch nicht, dass jede wartende Aufgabe nach längerer Verzögerung noch sinnvoll ist. Ein geplanter Zustand kann inzwischen überholt sein. Für einen Entwurf wird deshalb zusätzlich gefragt, welche Informationen unmittelbar vor der Wirkung erneut bewertet werden müssen. Eine bei der Aufnahme gültige Erlaubnis ist keine automatische Zusage, dass eine später ausgeführte Handlung weiterhin zur aktuellen Situation passt.

Für die Arbeitsleuchte wäre eine Reihe vollständiger Einschaltphasen vermutlich keine gute Bedienung. Drei schnelle Tastendrücke würden mehrere Durchgänge erzeugen, obwohl die Person vielleicht nur die aktuelle Phase verlängern wollte. Eine längere Gesamtdauer wäre dabei nicht einfach „zuverlässiger“, sondern eine andere Interpretation des Tastendrucks. Eine Warteschlange wird daher nur gewählt, wenn die einzelnen Aufträge eine eigenständige Bedeutung haben. Diese Bedeutung sollte auch nach der späteren Ausführung noch verständlich sein.

Die maximale Zahl wartender Aufträge ist ebenfalls eine Produktentscheidung. Ein beliebig großer Rückstand hilft nicht, wenn seine Ergebnisse nach Minuten niemand mehr erwartet. Für einen konkreten Ablauf wird deshalb festgelegt, wie Überlastung erkennbar wird und welche verlorene Anforderung akzeptabel ist. Ein still übergangener Auftrag kann schlimmer sein als eine sichtbare Ablehnung. Das Beispiel zeigt, warum die Wahl einer Warteschlange über eine einzelne YAML-Zeile hinausgeht.

Parallelität verlangt unabhängige Wirkungen

Mehrere Durchgänge können sinnvoll gleichzeitig laufen, wenn ihre Aufgaben einander nicht widersprechen. Sobald sie dasselbe Gerät mit unterschiedlichen Zielzuständen bedienen, muss die Reihenfolge der tatsächlichen Wirkungen betrachtet werden. Zwei voneinander getrennte Durchgänge sind nicht automatisch zwei voneinander unabhängige Auswirkungen. Für eine zeitlich begrenzte Leuchte ist diese Unterscheidung besonders anschaulich: Ein älterer Durchgang könnte abschalten, während ein neuerer seine Beleuchtungsphase noch fortsetzen möchte.

Deshalb wird im Beispiel kein Parallelbetrieb gewählt. Der letzte Wunsch soll den Zeitbezug bestimmen, und dafür braucht es eine eindeutige gemeinsame Entscheidung. Bei mehreren getrennten Empfängern oder vollständig getrennten Geräten könnte eine andere Struktur passend sein. Auch dann wird geprüft, ob gemeinsame Ressourcen oder eine gemeinsame Benachrichtigung die scheinbare Unabhängigkeit wieder aufheben. Die Anzahl unterschiedlicher Variablen im Code ist dafür weniger aussagekräftig als die tatsächlich berührten Dinge im Zuhause.

Für die Abnahme wird zusätzlich eine absichtlich langsame Antwort eingeplant. Dadurch entsteht eine Überlappung auch dann, wenn die normale Ausführung sehr schnell wirkt. Der Test dient nicht dazu, einen allgemeinen Geschwindigkeitswert zu ermitteln. Er prüft, ob die erklärte Behandlung eines weiteren Aufrufs weiterhin verständlich bleibt. Anschließend wird der gewöhnliche Ablauf erneut verwendet, damit die Störung nicht versehentlich Teil der späteren Konfiguration bleibt. Die Beobachtungen werden zusammen mit den ursprünglichen Erwartungen abgelegt. So bleibt nachvollziehbar, warum der gewählte Modus auch unter ungünstigen Bedingungen zum Zweck der Automation passt.

Abbruch, Neustart und Pflege mitdenken

Ein abgebrochener Ablauf macht bereits ausgeführte Aktionen nicht einfach ungeschehen. Wenn die Lampe schon eingeschaltet wurde, ist das eine erfolgte Wirkung. Für längere Abläufe wird daher überlegt, was bei einem Neustart der Umgebung oder einer bewussten Deaktivierung passieren soll. Das Beispiel mit zehn Sekunden ist überschaubar; eine stundenlange Wartephase verdient eine andere Betrachtung ihrer Wiederherstellung. Die Dokumentation zur Skriptsyntax ist die Grundlage für die verwendeten Aktionsfolgen und Warteaktionen.

Zur fertigen Beschreibung gehören schließlich der gewählte Zeitbezug, die Bedeutung eines zweiten Aufrufs und die Grenzen bei fremden Eingriffen. Diese wenigen Angaben helfen bei einer späteren Änderung mehr als die bloße Notiz des Modusnamens. Wenn aus der Testleuchte eine echte Alltagsfunktion wird, wird erneut geprüft, ob dieselben Annahmen gelten. Ein guter Modus ist damit kein universeller Standardwert, sondern die passende Antwort auf eine klar formulierte Frage nach überlappenden Anforderungen.