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).

[sewi]

Hier ist was für einen schönen Spezialfall, den wahrscheinlich sonst niemand hat, aber hey -


Ist eine Vorwarnung bei Präsenz-Ende für Dimmer. Am Ende der Präsenz wird das Licht kurz stark abgedimmt. Bewegt sich für weitere 10 Sekunden nichts, wird es abgeschaltet, anderenfalls wieder an.

Ich verwende das uhrzeitabhängige Dimmen der MDT Dimmer, die werden mit An-Aus angesteuert. Es passiert selten dass ich mich so lange nicht bewege, dass der Präsenzmelder mich nicht mehr erkennt, aber wenn das passiert ist ein kurzes Winken weniger aufwändig als wieder zum Taster zu gehen (ist in meinem Schlafzimmer, dort geht bei Bewegung nur das Nachtlicht unter dem Bett automatisch an). Im Endeffekt ist das wie das Treppenlicht, außer dass es eben kein periodisches "bin noch präsent" vom PM benötigt, und die Nachlaufzeit weiterhin beim Präsenzmelder eingestellt bleiben kann.

Benötigt:
- A/B: Präsenzstatus vom Präsenzmelder, mit welchem Timeout auch immer
- C/D: Licht-Status vom Aktor, damit die Vorwarnung nur bei eingeschaltetem Licht passiert.

Ausgabe:
- O1: Sendet ein "Aus" wenn das Präsenzende tatsächlich eingetreten ist. Verwendet zum Abschalten der Lichter.
- O2: Sendet den Dimmwert bei der Vorwarnung.
- O3: Sendet wieder ein "Ein", wenn die Vorwarnung abgebrochen wird - somit setzt der Aktor das uhrzeitabhängige Dimmen fort.

image.png

Zustände 1-5 sind Initialzustände, wo ich nicht alle Werte weiß. In diesem Fall wird gemacht was Sinn zu machen scheint (bei Präsenzende jedenfalls mal das Licht auf "Aus" setzen), aber im Endeffekt wird nur der Zustand mitverfolgt, bis man alle Werte hat.

6-7 sind die Zustände wenn man anwesend ist, und Licht Ein/Aus schaltet - wird mitverfolgt.
8-9 sind die Zustände wenn das Licht Ein/Aus geschaltet wird ohne dass wer präsent ist - wird mitverfolgt, zusätzlich geht er nach 10 Minuten "Licht ein" ohne Präsenz auch in die Vorwarnung, mit der Annahme dass das Licht von irgendwo manuell geschalten wurde ohne dass der PM das mitbekommen hat - damit es auf jeden Fall wieder aus ist. Die Zeit kann man natürlich verstellen oder raustun, wenn einem das nicht passt.

10 ist die Vorwarnung bei Präsenzende.
Bewegt man sich - geht's in den Zustand 11 - und dann wieder auf "Präsenz/Licht". Das ist ein Übergangszustand, einfach damit der Vorgang nachvollziehbar bleibt (ich protokolliere den aktuellen Zustand).
Bewegt man sich nicht - geht's in Zustand 12 - und dann auf "Keine Präsenz/Licht", wieder ein Übergangszustand, mit der Annahme, dass das Aus-RM Objekt gleich darauf kommt - dann geht er auf "Keine Präsenz/Kein Licht".

Bei beiden Übergangszuständen werden die relevanten Änderungen auch abgebildet, falls z.B. das "Aus RM" Objekt in den 1/10 Sekunden vom Zustand 12 kommt, geht er gleich auf "Keine Präsenz/Kein Licht".


image.png

Naja, und hier die Ausgänge.

Ausgang 1: Zur "Licht schalten" GA hinzufügen, auch falls es mehrere Lichter gibt.

image.png

Ausgang 2: Zur GA für "Dimmen absolut" hinzufügen, das ist die Vorwarnung.

image.png


Ausgang 3: Zur GA für "Licht einschalten" hinzufügen, das ist das Wiedereinschalten für Bewegung bei der Vorwarnung. Ist separat zu Ausgang 1, denn bei Präsenzende schalte ich alles ab, aber sonst geht's mir nur um das "Haupt" Deckenlicht.
image.png

Export-String

OpenKNX,cv1,0xA012:0x54/DFA:0x8/4§a~Name=Pr%C3%A4senz-Ende%20X§a~Active=1§a~SymbolPairAB=1§a~SymbolPairCD=1§a~StartupDelayTime=0§a~Output1Name=Pr%C3%A4senz-Ende%20senden§a~Output1Dpt=10§a~Output2Name=Licht%20dimmen§a~Output2Dpt=51§a~Output3Name=Licht%20schalten§a~Output3Dpt=10§a~SymbolAName:2=Pr%C3%A4senz-Status§a~SymbolAInput:2=1§a~SymbolCName:2=Licht-Status§a~SymbolCInput:2=1§a~z01Name=Initial§a~d01A=2§a~d01B=3§a~d01C=4§a~d01D=5§a~z02Name=Pr%C3%A4senz1-LichtX§a~d02B=3§a~d02C=6§a~d02D=7§a~z03Name=Pr%C3%A4senz0-LichtX§a~d03A=2§a~d03C=8§a~d03D=9§a~z03o1Send=6§a~z03o1Dpt1=0§a~z04Name=Pr%C3%A4senzX-Licht1§a~d04A=6§a~d04B=10§a~d04D=5§a~z05Name=Pr%C3%A4senzX-Licht0§a~d05A=7§a~d05B=9§a~d05C=4§a~z06Name=Pr%C3%A4senz%20und%20Licht%20Ein§a~d06B=10§a~d06D=7§a~z07Name=Pr%C3%A4senz%20und%20Licht%20Aus§a~d07B=9§a~d07C=6§a~z08Name=Keine%20Pr%C3%A4senz%20und%20Licht%20Ein§a~d08A=6§a~d08D=9§a~d08T=10§a~d08TBase=1§a~d08TTime=10§a~z09Name=Keine%20Pr%C3%A4senz%20und%20Licht%20Aus§a~d09A=7§a~d09C=8§a~z09o1Send=6§a~z09o1Dpt1=0§a~z10Name=Vorwarnung%3A%20Pr%C3%A4senz-Ende%20bei%20Licht%20Ein§a~d10A=11§a~d10D=9§a~d10T=12§a~d10TTime=10§a~z10o2Send=6§a~z10o2Dpt5001=10§a~z11Name=Abbruch%3A%20Pr%C3%A4senz%20w%C3%A4hrend%20Vorwarnung§a~d11B=10§a~d11D=7§a~d11T=6§a~d11TBase=3§a~d11TTime=1§a~z11o3Send=6§a~z12Name=Vorwarnung-Timeout§a~d12A=6§a~d12D=9§a~d12T=8§a~d12TBase=3§a~d12TTime=1§a~z12o1Send=6§a~z12o1Dpt1=0§;OpenKNX

[traxanos]

So special ist das garnicht. mumpf läst nutzt z.B. einen Summer um das gleiche zu erreichen

[willisurf]

Ansonsten, wenn es „nur“ um die Vorwarnung geht, lässt sich das auch mit zwei parallelen VPM Kanälen lösen, viele Wege….

[sewi]

Viele Wege führe nach Rom. Ich persönlich mag die Zustandsautomaten sehr gerne, weil immer ganz klar ist, in welchem Zustand sie sich befinden, wie sie dort hingekommen sind, und was dort möglich ist. Wobei, ich bin erst bei 4/10 benutzt, da geht noch mehr.

[mumpf]

Cool gemacht, ist ein schönes Beispiel für StateEngine. Ironischerweise sieht man hier gleich die Vor- und Nachteile von Zustandsautomaten. Deine Zustände 1-10 sind nämlich nichts anderes als ein AND mit einem invertiertem Eingang (Präsenz), dass mit undefinierten Eingängen umgehen kann und 10 Minuten Einschaltverzögerung hat. Für den Teil wäre ganz klar ein Logikkanal einfacher und IMO auch übersichtlicher, das hat all die Übergänge PräsenzQ-LichtR (Q und R sind {undef, 0, 1}) nämlich "im Bauch". Aber die Übergänge 10, 11, 12 sind dann im Logikmodul ungleich schwerer zu realisieren, deswegen macht eine Gesamtrealisierung in der StateEngine durchaus Sinn.

Sehe ich das richtig, dass nach dem Runterdimmen auf 10% - beim Winken - dann ein Einschaltbefehl geschickt und somit wieder auf 100% gedimmt wird? Das ist so der einzige Punkt, den ich anders machen würde (mit einem dazwischengeschalteten TOR) und hinterher den vorherigen Dimmwert schicken würde.

Gruß, Waldemar

[sewi]

Klar - ich hab's bewusst in der StateEngine gehalten, weil somit ist es unabhängig. Die ganze Funktionalität ist in einem "Kanal", den ich leicht kopieren kann, und den ich wahrscheinlich auch in 2-3 Jahren noch verstehen werde.

Wegen dem Abbruch des Abschaltens: wenn während der Vorwarnzeit wieder Präsenz ist, wird ein "Ein" an den Dimmaktor gesendet - der setzt dann das uhrzeitabhängige Dimmen fort. Wenn ich einen fixen Dimmwert senden würde, würde er den halten, und nicht über die Zeit herunterdimmen.

z.B. um 22:19 war's 32%, aktuell ist es 26%, um 23:00 wird's 15% sein, und dazwischen interpoliert er eben. Klingt unruhig, ist es aber nicht - da er über eine lange Zeit dimmt, fällt's nicht auf, gegen die Bettzeit wird's einfach immer dunkler/wärmer (dank Philips Dim2Warm) was halt sehr angenehm ist.

Wenn ich um diese Uhrzeit auf 100% schalten würde, bekomm ich bald Kopfweh - aber z.B. um 20:00 ist schon noch 100%.