Wer wie unsereiner offenbar mit einem eher schlichten Geist ausgestattet sein mag, darf wohl auch einmal mit Sorgen über die Implementierungen von Smarthome aufwarten dürfen. Damit nicht auch die Klugen unter uns verwirrt werden, hier einige Beispiele, wie subtil die Entwickler denken.

Die folgenden Beispiele sind bei der Überarbeitung meines WIKI-Beitrages zu einer Garagentorsteuerung entstanden. Ein Tür-/Fensterkontakt zeigt hierbei den Zustand des Tores an.

Los geht's ..

Will man sich über den Zustand des Garagentores informieren lassen, so gibt es auch einige Hürden zu überwinden. Die Entwickler würden ihrem Ruf nicht gerecht werden, hätten sie nicht auch hierzu Verwirrendes beizutragen.

Ziel ist es, dass alle fünf Minuten eine PUSH-Nachricht versandt wird, die über den Zustand des Tores informiert.

Erster Versuch ..

Bewertung des Tür-/Fensterkontaktes

Leider liefert diese Regel nicht das Gewünschte. Sie wird genau einmal ausgeführt und das war's. Wenn man genau hinschaut, kann man den Grund erkennen: Es wird nicht der Zustand (offen bzw. geschlossen), sondern dessen Änderung erfasst. 

zweiter Versuch ..

Bewertung des Tür-/Fensterkontaktes UND-verknüpft mit Zeitintervall

Diese Regel tut endlich genau das, was gewünscht ist: Alle fünf Minuten wird eine PUSH-Meldung versandt. Der entscheidende Unterschied ist auf den ersten Blick kaum zu erkennen. Bei genauerem Hinschauen sieht man, dass ein kleines Wörtchen ausgetauscht wurde: wird → ist. Eine Konsequenz aus der gewählten Implementierung ist, dass die PUSH-Mitteilung auch noch nach Schließen des Tores einmal versandt wird.

einen vierten Versuch findet man ab hier ..

erster Kontrollversuch ..

Bewertung des Tür-/Fensterkontaktes ODER-verknüpft mit Zeitintervall

Bei einer ODER-Verknüpfung wandelt sich erneut das ist → wird.

ein zweiter Kontrollversuch ..

Bewertung des Sensor UND-verknüpft mit Abwesenheitszustand

Und schon wieder wandelt sich das Ganze.

Vorsichtig (man weiß ja nie) möchte ich nach diesen Erfahrungen eine erste Vermutung äußern ..

Merke:

Wird in der WENN-Sektion nur ein Sensor eingefügt, so wird dessen Änderung bewertet. Verknüpft man den Wert des Sensors jedoch mittels UND mit einem Zeitintervall, Abwesenheit, .., so wird der Zustand des Sensorwertes selbst ausgewertet. Es kommt noch verrückter: Verwendet man statt der UND- eine ODER-Verknüpfung, wird wieder die Änderung bewertet.

Ist doch alles logisch, oder? Mir fehlt es zumindest an der - für mich - erforderlichen Transparenz.

Unsereiner denkt offensichtlich zu schlicht. Ich hatte zu Zeiten als der Master noch Diplom hieß und man seine Doktorarbeiten selbst schreiben musste (und das sogar auch noch in Deutsch) immer gedacht, dass solche Programmierung eine Art Agrarinformatik à la Kraut&Rüben darstellt. Ja, ich dachte gar, dass man bei derartigen Ereignisgenerierungen zwei Welten unterscheiden (können) sollte ..

• Bewertung von Zuständen (Pegeltriggerung)
• AN
• AUS
• Bewertung von Änderungen (Flankentriggerung)
• AN→AUS (abfallend)
• AUS→AN (ansteigend)

Mein Fazit ..

Entweder bin ich zu alt für diesen neuen Wirrwarr oder die heutige Komplexität und Intransparenz der neuen Informatik überfordert mich.☹️