Fensterzustände in verständliche Erinnerungen übersetzen

Ein Fenster wird geöffnet, kurz darauf wieder geschlossen, und trotzdem erscheint eine Erinnerung. Oder es bleibt lange offen, aber nach einem Neustart kommt keine Meldung. Solche Situationen entstehen häufig nicht durch komplizierte Technik, sondern durch eine unklare Beschreibung des gewünschten Verhaltens. „Erinnere mich an offene Fenster“ lässt offen, wann die Erinnerung beginnt, wann sie endet und was bei fehlenden Informationen passieren soll.

Ein guter Entwurf beantwortet diese Fragen zuerst in Alltagssprache. Das folgende Beispiel verwendet einen erfundenen Fensterkontakt in einem Leseraum. Nach längerem Öffnen soll eine lokale Erinnerung erscheinen. Beim bestätigten Schließen soll sie verschwinden. Die Beispielregel dient der Aufmerksamkeit und erhebt keinen Anspruch, ein vollständiges Sicherheits- oder Gebäudeschutzsystem zu sein. Sämtliche Namen und Zeitangaben sind frei gewählt.

Was ein Kontakt tatsächlich meldet

Ein binärer Kontakt liefert grundsätzlich eine begrenzte Information. Ob eine Installation daraus „offen“ oder „geschlossen“ darstellt, hängt auch von der Geräteklasse und der korrekten Zuordnung ab. Die Binary-Sensor-Dokumentation beschreibt diese Darstellung. Vor jeder Automation wird deshalb am realen Gerät geprüft, welcher Zustand beim Öffnen und welcher beim Schließen ankommt.

Diese Zuordnung sollte nicht aus einem Symbol geraten werden. Ein vertauschtes Signal kann auf einer übersichtlichen Karte zunächst plausibel aussehen und die Erinnerungslogik vollständig umkehren. Im fiktiven Test wird das Fenster bewusst geöffnet und geschlossen, während der tatsächliche Entitätszustand beobachtet wird. Erst danach gilt die Annahme: on bedeutet geöffnet, off bedeutet geschlossen.

Ein einfacher Kontakt unterscheidet außerdem nicht automatisch zwischen verschiedenen Öffnungsarten. Wenn das Gerät keine entsprechende Information liefert, sollte die Oberfläche keine Kippstellung behaupten. Ebenso wenig beweist ein geschlossener Kontakt eine bestimmte mechanische Verriegelung. Die Erinnerung verwendet deshalb nur jene Aussage, die aus der geprüften Quelle tatsächlich hervorgeht.

Einen Öffnungsvorgang als Einheit betrachten

Für das Beispiel beginnt ein Vorgang mit einem bestätigten Wechsel von geschlossen zu geöffnet. Innerhalb dieses Vorgangs darf höchstens eine erste Erinnerung entstehen. Ein bestätigtes Schließen beendet ihn und nimmt die Erinnerung zurück. Wird später erneut geöffnet, beginnt ein neuer Vorgang mit einer neuen Wartezeit. Diese Beschreibung verhindert viele unbeabsichtigte Wiederholungen.

Die Dauer wird aus dem gewünschten Nutzen abgeleitet. Zehn Minuten dienen hier nur als leicht prüfbarer Demonstrationswert. Ein Raum mit kurzen Lüftungsphasen kann andere Anforderungen haben als ein Raum, in dem das Fenster absichtlich lange offen bleibt. Die Zeit ist daher eine veränderbare Regelentscheidung, kein allgemeiner Rat zur richtigen Lüftungsdauer.

Auch die Bedeutung einer Bestätigung muss feststehen. Wenn jemand eine Nachricht wegklickt, ist das Fenster dadurch nicht geschlossen. Die technische Quelle bleibt maßgeblich für den Fensterzustand. Eine optionale Funktion „später erinnern“ wäre eine eigene Entscheidung mit einer eigenen Frist. Sie sollte nicht heimlich aus dem bloßen Entfernen einer Meldung abgeleitet werden.

Eine kleine erste Automation

Das folgende Beispiel zeigt eine einzelne Automation für den YAML-Editor. Es verwendet ausschließlich erfundene Entitäten und erzeugt eine lokale persistente Benachrichtigung. Vor der Verwendung müssen Entität und gewünschte Dauer angepasst werden. Die zusätzliche Bedingung prüft beim Ausführen noch einmal den gemeldeten Zustand, damit die Aktion zu ihrer aktuellen Grundlage passt.

id: beispiel_leseraum_fenster_erinnerung
alias: "Beispiel Leseraum Fenster erinnern"
triggers:
  - trigger: state
    entity_id: binary_sensor.beispiel_leseraum_fenster
    from: "off"
    to: "on"
    for: "00:10:00"
conditions:
  - condition: state
    entity_id: binary_sensor.beispiel_leseraum_fenster
    state: "on"
actions:
  - action: persistent_notification.create
    data:
      notification_id: beispiel_leseraum_fenster
      title: "Fenster im Beispielraum prüfen"
      message: "Der Kontakt meldet seit zehn Minuten geöffnet."
mode: single

Die Auslösung setzt einen beobachteten Wechsel von off nach on voraus. Das ist bewusst enger als „irgendwann ist der Zustand offen“. Ein Übergang aus einem unbekannten Zustand wird damit nicht als frisch beobachtetes Öffnen behandelt. Diese Entscheidung vermeidet eine erfundene Öffnungszeit, bringt aber eine erkennbare Grenze mit sich: Bereits offene Fenster benötigen nach einem Neustart eine gesonderte Behandlung.

Die Dokumentation der Automationsauslöser weist außerdem darauf hin, dass eine laufende Wartezeit mit for einen Neustart oder das Neuladen von Automationen nicht überlebt. Das einfache Beispiel eignet sich deshalb für eine bewusst begrenzte Erinnerung. Wer unterbrechungsfest erinnern möchte, muss die Zeitlogik erweitern und das Verhalten beim Start ausdrücklich definieren.

Das Schließen beendet die Erinnerung

Eine zweite kleine Automation nimmt die Nachricht zurück, sobald der Kontakt geschlossen meldet. Dafür wird dieselbe feste Benachrichtigungskennung verwendet. So betrifft die Aktion genau diese Erinnerung und keine anderen Hinweise. Die Funktionen zum Erstellen und Entfernen beschreibt die Persistent-Notification-Dokumentation.

id: beispiel_leseraum_fenster_erledigt
alias: "Beispiel Leseraum Fenster geschlossen"
triggers:
  - trigger: state
    entity_id: binary_sensor.beispiel_leseraum_fenster
    to: "off"
actions:
  - action: persistent_notification.dismiss
    data:
      notification_id: beispiel_leseraum_fenster
mode: single

Die Rücknahme wird an eine positive Information gebunden: Der Kontakt meldet geschlossen. Eine nicht erreichbare Quelle darf dieselbe Wirkung nicht ohne weitere Überlegung auslösen. Sonst würde ausgerechnet eine unterbrochene Verbindung eine bestehende Erinnerung scheinbar erledigen. Die offene Frage verschwindet dann von der Oberfläche, obwohl ihr tatsächlicher Zustand nicht mehr bekannt ist.

Eine nachträgliche Zustandsprüfung im Ablauf reduziert mögliche Fehlentscheidungen, macht getrennte Ereignisse aber nicht zu einer unteilbaren Operation. Für einen sehr knapp aufeinanderfolgenden Schließvorgang und eine gleichzeitig entstehende Meldung ist deshalb ein gezielter Test sinnvoll. Falls eine veraltete Nachricht zurückbleibt, braucht der Entwurf eine zusätzliche Abgleichregel, die Meldung und aktuellen Zustand wieder zusammenführt.

Neustarts benötigen eine eigene Vereinbarung

Nach einem Start kann ein Fenster als geöffnet gemeldet sein, ohne dass die Öffnungszeit bekannt ist. Für diese Situation gibt es mehrere vertretbare Entwürfe. Die Installation könnte nach einer neuen Beobachtungsfrist erinnern. Sie könnte sofort einen neutralen Hinweis anzeigen, dass ein offener Zustand vorliegt. Oder sie könnte eine vorher gespeicherte Frist wieder aufnehmen, sofern diese verlässlich zu demselben Vorgang gehört.

Keine dieser Varianten sollte so formuliert werden, als kenne das System mehr Vergangenheit, als tatsächlich gespeichert wurde. Ein Hinweis „seit mindestens zehn Minuten offen“ ist nur gerechtfertigt, wenn diese Dauer beobachtet oder nachvollziehbar erhalten wurde. Andernfalls ist „beim Systemstart als geöffnet gemeldet“ die genauere Aussage. Eine kleine sprachliche Anpassung kann hier einen wichtigen Wahrheitsunterschied ausdrücken.

Für eine gespeicherte Fälligkeit bietet sich ein Datums- und Zeithelfer als Baustein an. Die Input-Datetime-Dokumentation beschreibt seine Eigenschaften einschließlich Wiederherstellung. Der vollständige Entwurf benötigt zusätzlich einen Abgleich beim Start: Ist die Quelle verfügbar, gehört die Frist noch zum aktuellen Vorgang, und ist sie bereits überschritten? Ein Zeithelfer allein beantwortet diese Fragen nicht.

Fehlende Daten bleiben ein eigener Zustand

Ein Fensterkontakt kann zeitweise unavailable oder unknown melden. Diese Zustände sind keine weiteren Schreibweisen für geschlossen. Im Beispiel wird die normale Erinnerung dann nicht durch eine sichere Zustandsbehauptung ersetzt. Stattdessen zeigt die Oberfläche, dass die Quelle gerade keine verlässliche Grundlage liefert. Ob daraus eine zusätzliche technische Meldung entsteht, hängt von Dauer und Bedeutung des Ausfalls ab.

Eine kurze Unterbrechung muss nicht sofort sämtliche Personen benachrichtigen. Ein länger fehlender Kontakt kann dagegen eine Wartungsaufgabe rechtfertigen. Diese Aufgabe sollte anders heißen als die Fenstererinnerung, etwa „Kontakt im Beispielraum prüfen“. Dadurch bleibt deutlich, ob eine Handlung am Fenster oder eine Prüfung der Messquelle gemeint ist. Beide Fälle benötigen unterschiedliche nächste Schritte.

Bei der Rückkehr des Kontakts wird der aktuelle Zustand neu eingeordnet. Meldet er geschlossen, kann eine offene Erinnerung erledigt werden. Meldet er geöffnet, bleibt die Öffnungsdauer möglicherweise unklar. Der Entwurf legt dafür denselben vorsichtigen Weg wie beim Systemstart fest. So entsteht kein zweiter, widersprüchlicher Sonderfall für eine technisch ähnliche Wissenslücke.

Mehrere Fenster ohne Meldungsflut

Bei mehreren Kontakten ist zunächst zu entscheiden, ob jede Öffnung separat behandelt oder eine gemeinsame Raumübersicht erzeugt wird. Einzelne Erinnerungen sind präzise, können aber schnell unübersichtlich werden. Eine Sammelmeldung ist ruhiger, muss jedoch eindeutig nennen, welche Kontakte weiterhin geöffnet melden. Ein allgemeiner Satz wie „Es ist noch etwas offen“ hilft bei der tatsächlichen Prüfung wenig.

Im Entwurf erhält jeder Vorgang eine klare Zuordnung. Das Schließen eines Fensters darf nicht die Erinnerung für ein anderes löschen. Bei einer Sammelkarte wird die Liste deshalb aus den aktuell bekannten Einzelzuständen aufgebaut. Nicht erreichbare Kontakte erscheinen getrennt von bestätigten offenen Kontakten. So kann eine fehlende Datenquelle nicht versehentlich als zusätzlicher Öffnungszustand in derselben Liste landen.

Die erste Version sollte trotzdem mit einem einzigen Kontakt beginnen. Damit lassen sich Zeitlogik, Texte und Rücknahme überschaubar prüfen. Erst wenn diese Abläufe verstanden sind, wird die Lösung verallgemeinert. Eine frühzeitig stark abstrahierte Automation spart möglicherweise Zeilen, erschwert aber die Suche nach einem falsch zugeordneten Fenster oder einer ungewollt gemeinsam genutzten Frist.

Mit einer Ereignisfolge testen

Der wichtigste Test besteht aus einer vorher notierten Folge: öffnen, vor Ablauf schließen, erneut öffnen und länger warten. Erwartet wird nur beim zweiten Vorgang eine Erinnerung. Anschließend wird geschlossen und die Nachricht muss verschwinden. Dieser Test prüft den tatsächlichen Auslöser. Das manuelle Ausführen einer Aktion bestätigt lediglich, dass eine Nachricht erstellt werden kann, nicht die Zeitlogik davor.

Danach folgt eine Unterbrechung während der Wartezeit. Das einfache Beispiel soll seine dokumentierte Grenze zeigen; eine erweiterte Variante muss ihre vereinbarte Wiederaufnahme erfüllen. Ebenso wird ein Ausfall nach bereits erzeugter Erinnerung geprüft. Hier interessiert vor allem, ob eine bestehende offene Frage sichtbar bleibt und ob die Oberfläche den jetzt unbekannten Zustand verständlich erklärt.

Ein weiterer Test stellt Öffnen und Schließen zeitlich eng nebeneinander. Dabei wird beobachtet, ob eine verspätete Aktion eine bereits erledigte Meldung erneut erzeugt. Die erwartete Endlage wird vorab festgelegt: Bei bestätigtem geschlossenem Zustand soll keine aktive Fenstererinnerung übrig bleiben. Das Ergebnis zählt mehr als die bloße Tatsache, dass jeder einzelne Automationslauf ohne Fehlermeldung abgeschlossen wurde.

Ruhezeiten mit offenen Fragen vereinbaren

Soll während einer bestimmten Phase keine neue Nachricht erscheinen, muss trotzdem feststehen, was mit einer inzwischen fälligen Erinnerung geschieht. Im Beispiel bleibt die offene Frage intern bestehen. Nach Ende der Ruhephase wird zuerst der aktuelle Kontaktzustand geprüft. Nur ein weiterhin bestätigtes Öffnen rechtfertigt dann einen neuen Hinweis. Eine stumm geschaltete Benachrichtigung ist keine abgeschlossene Aufgabe.

Der Meldungstext sollte in diesem Fall keine unzutreffende Dauer aus dem Zeitpunkt des Versands ableiten. Die Erinnerung kann später zugestellt werden als ursprünglich fällig. Für das Verständnis genügt häufig die Aussage, dass das Fenster weiterhin geöffnet gemeldet wird. Falls eine genaue Dauer angezeigt werden soll, braucht sie einen belastbaren gespeicherten Beginn und eine klare Behandlung zwischenzeitlicher Datenlücken.

Die Erinnerung im Alltag verständlich halten

Nach der Einführung wird nicht nur gezählt, wie oft eine Meldung erschien. Interessanter ist, ob sie eine nachvollziehbare Frage zum richtigen Zeitpunkt stellte. Häufig weggeklickte Hinweise können auf eine unpassende Dauer oder eine unklare Formulierung hindeuten. Sie sind kein Beweis dafür, dass Personen unaufmerksam wären. Der Entwurf sollte sich an der tatsächlichen Aufgabe orientieren.

Eine kurze Beschreibung neben der Konfiguration hält fest, wann ein Vorgang beginnt, wann er endet und was bei Neustarts oder fehlenden Daten geschieht. Diese wenigen Sätze erleichtern spätere Änderungen erheblich. Aus einem simplen Kontakt entsteht so eine brauchbare Erinnerung: mit klarer Grundlage, begrenzter Aussage und einem Ende, das genauso sorgfältig gestaltet ist wie ihr Beginn.