OpenKNX StateEngine: Universelle Zustandsautomaten in KNX

[coko]

Version 0.8.2 der StateEngine mit den Fixes ist nun verfügbar und enthält 4 Fehlerkorrekturen:

• Für die zwei bereits oben aufgeführten Probleme in der Eingangsverarbeitung
• Für noch seltenere Randfälle bei Nutzung der Rekonstruktionsfunktion:
  • Wenn ein zuvor inaktiver Kanal aktiv geschaltet wurde
    Beim Laden der beim Geräte-Shutdown gespeicherten Modul-Kanal-Daten wurde nicht korrekt geprüft, ob der Kanal zuvor inaktiv war.
    • Dies hätte bei erlaubtem Pausieren dazu geführt, dass der Automat (unabhängig von der gewählten Konfiguration) pausiert startet, nachdem die Konfiguration von Inaktiv auf Aktiv geändert wurde
  • Wenn das Gerät fast zeitgleich zum Timeout-Ende neugestartet wurde, dann hätte die Rekonstruktionsfunktion zu fehlerhaftem Rest-Timeout führen können
    • Eine Fortsetzung hätte mit extrem langem Timeout oder unter Ignornieren des gespeicherten Timeouts erfolgen können

Die Probleme waren jeweils seit ersten öffentlichem Release (ggf. bei Einführung des betroffenen Features) enthalten, ein Update ist entsprechend zu empfehlen; kann aber auch noch warten bis ich den Pre-Release-Status entferne. In meiner Test- und Produktivumgebung gab es keine Nebeneffekte. Ich wäre Nutzern der Rekonstuktionsfunktion dankbar für ein Feedback, dass es so weiter läuft wie erwartet, da sich die Anpassungen nicht so gut testen lassen wie ich mir das wünschen würde

Ansonsten wünsche ich erst mal weiter frohe Ostern.

[coko]

Version 0.8.2 der StateEngine mit den Fixes ist nun verfügbar und enthält 4 Fehlerkorrekturen:
[...]
Die Probleme waren jeweils seit ersten öffentlichem Release (ggf. bei Einführung des betroffenen Features) enthalten, ein Update ist entsprechend zu empfehlen; kann aber auch noch warten bis ich den Pre-Release-Status entferne.

Update-Hinweis:Hatte den Status der OpenKNX StateEngine v0.8.2 gestern nun in ein ein reguläres Release geändert.

[willisurf]

Mal ein Beispiel für die Anwendung des DEA inkl. eines bedingten Zustandsübergangs.

Vorab: Aufgabenstellung ist die Durchsage "Bitte Waschmaschine ausräumen" über zwei Sonos Lautsprecher. Das Signal Waschmaschine (WM)-fertig wird generiert, wenn die Stromerfassung ein Abschalten erkennt. Damit wird ein RS-FlipFlop eines Logikkanals gesetzt. Anwesenheit im Raum der Waschmaschine setzt das RS-FlipFlop zurück.
Wenn Schlaf aktiv ist, wird dieses Signal über einen Logikkanal durch ein TOR blockiert und gleichzeitig setzt Schlaf aktiv die Durchsagekette zurück.

Der DEA soll die Durchsage in wählbaren Abständen 3x durchführen, bei Abwesenheit soll diese Durchsagekette erst starten, nachdem wieder jemand anwesend ist. Dazu wird der bedingte Statusübergang b) in State 1 genutzt. Der Rest ist nahezu selbsterklärend, bei Unklarheiten gerne fragen.
image.png
Neben der Übersichtlichkeit ist ein weiterer Vorteil des DEA, das er 4 KOs gleichzeitig schreiben kann. Dies wird hier genutzt, um parallel beide Sonos Lautsprecher zu aktivieren.
image.pngDie Ausgangsdefinition ist einfach und sieht für beide Kanäle identisch aus.
image.pngDas Auslösen einer PopUp Meldung, wenn die Waschmaschine bei Abwesenheit fertig ist (State2) waren dann nur noch ein paar Mausklicksimage.png

[mumpf]

Hi Bernhard,

schönes Beispiel - vor allem Spiel . Aber willst Du wirklich Durchsagen in einer Leeren Wohnung haben?

1. Wenn Du nach der 1. oder 2. Durchsage weggehst (Abwesend = 1), kommen die restlichen trotzdem. Hier würde ich bei 3E-16E eine 2 erwarten.
2. Nach 8h Abwesenheit werden die Durchsagen dann abgespielt? Hier hätte ich beim Ablauf die 1 statt 3 erwartet.
3. Schlafen bricht die Durchsagen ab. Willst Du nicht nach dem Aufwachen - vielleicht nach einer längeren Pause - an die volle Waschmaschine erinnert werden? Dafür würde sich ein Zustand "Warten nach Aufwachen" anbieten.
4. Derzeit ist es so, dass wenn die Waschmaschine Nachts (während Schlafen) fertig wird die gesamte Ansagekette durchlaufen wird. Die Ansagen werden - wie Du oben geschrieben hast - durch ein TOR unterdrückt. Aber der Monk in mir sagt, dass das TOR nur ein zusätzliches Sicherheitskriterium sein sollte und die SM selber den Fall auch behandeln sollte. Und es wäre ein schönes Beispiel für Mehrschrittige bedingte Übergänge: a prüft auf Schlafen (1> 1, 0> ELSE), b prüft weiterhin Abwesend und in A1 trägst Du a> ein.

Gruß, Waldemar

[willisurf]

Wenn Du nach der 1. oder 2. Durchsage weggehst (Abwesend = 1), kommen die restlichen trotzdem. Hier würde ich bei 3E-16E eine 2 erwarten.

Sehr gute Idee!

Nach 8h Abwesenheit werden die Durchsagen dann abgespielt? Hier hätte ich beim Ablauf die 1 statt 3 erwartet.

Ja, ist besser!

Schlafen bricht die Durchsagen ab. Willst Du nicht nach dem Aufwachen - vielleicht nach einer längeren Pause - an die volle Waschmaschine erinnert werden? Dafür würde sich ein Zustand "Warten nach Aufwachen" anbieten.

Derzeit ist es so, dass wenn die Waschmaschine Nachts (während Schlafen) fertig wird die gesamte Ansagekette durchlaufen wird. Die Ansagen werden - wie Du oben geschrieben hast - durch ein TOR unterdrückt. Aber der Monk in mir sagt, dass das TOR nur ein zusätzliches Sicherheitskriterium sein sollte und die SM selber den Fall auch behandeln sollte. Und es wäre ein schönes Beispiel für Mehrschrittige bedingte Übergänge: a prüft auf Schlafen (1> 1, 0> ELSE), b prüft weiterhin Abwesend und in A1 trägst Du a> ein.

Das habe ich nicht genau genug beschrieben. Waschmaschine fertig wird durch ein TOR geschickt, würde also Morgens die Kette wieder auslösen. Wenn diese allerdings bereits begonnen hat, wird sie aktuell abgebrochen. Da überlege ich mal einen State für das Warten in der Nacht einzuführen.

Aber natürlich vertraue ich Deinem TOR, da ist ja viel Test und Entwicklung reingeflossen (mehr als bei den einfachen Logiken).

Edit: Denkfehler von mir mit dem TOR, da würde ja Morgens das Event WM fertig nicht durchkommen, wenn es in der Nacht passiert ist. Ich baue also noch so einen Wartestate für die Nacht ein und stelle die überarbeitete Version dann hier vor.

Vielen Dank für die Verbesserungen Waldemar!

[willisurf]

Vielen Dank nochmals mumpf für die Anregungen und Verbesserungen. Funktionalität ist jetzt deutlich verbessert.
Das TOR gibt es jetzt nicht mehr, das Signal Waschmaschine Fertig geht direkt in den DEA.
Schlaf hat immer Priorität, auch gegenüber Abwesenheit. In beiden Fällen wird die Ansage nach Ende Schlaf oder Ende Abwesenheit nachgeholt.

Ein interessantes Detail ist die geschachtelte Abfrage der bedingten Übergänge.
Im State 1 wird bei WM Fertig zuerst durch a) auf Schlaf geprüft. Wenn Schlaf nicht aktiv ist, wird über ELSE mit b) auf Abwesenheit geprüft.

Parallel wird der bedingte Übergang b) nochmals im State 2 ausgewertet.
image.pngimage.png

[Fidelis]

Braucht man das? Vermutlich nicht... Will man das trotzdem haben? Auf jeden Fall!
Ich finde es immer wieder beeindruckend mit welcher Detail-Verliebtheit viele hier ihre "Hirngespinste" in die Praxis übertragen. Einfach großartig!

[coko]

willisurf vielen Dank fürs Teilen des Beispiels. Werde das dann auch noch mal mit aufnehmen in die Link-Liste.

Zur Waschmaschine-Fertig-Erkennung hatte ich vor einiger Zeit auch schon mal ein Beispiel veröffentlicht:
https://knx-user-forum.de/forum/öffe...21#post2081821

Springst Du bei Wartezeit während Abwesenheit oder Schlaf bewusst irgendwann wieder in den Zustand 1 zurück? Dann geht die Nachricht doch ggf. komplett verloren...

[willisurf]

Springst Du bei Wartezeit während Abwesenheit oder Schlaf bewusst irgendwann wieder in den Zustand 1 zurück? Dann geht die Nachricht doch ggf. komplett verloren...

Ja, das mache ich nach 10h oder 14h Timeout. Wenn man bis dahin die Waschmaschine nicht ausgeräumt hat oder mal in dem Raum war, ist es irgendwie auch egal….

bzgl. Abwesenheit wöre noch zu ergänzen, das ich beim Verlassen einen Hinweis an der Ausgangstür bekomme, wenn Wäsche fertig und ich den Verlassenmodus aktiviere.
Wenn die Waschmaschine während der Abwesenheit beendet wird, gibt es noch eine Pushnachricht aufs Handy (aber auch nur dann).