OpenKNX StateEngine: Universelle Zustandsautomaten in KNX

[coko]

wird das Modul denn Teil des Fingerprint oder des VirtualPresence?

In der Garden-Control Applikation ist das Modul Zustandsautomaten nun testweise integriert, mit 4 Kanälen. Die Größe der Konfigurationsparameter hat alleine damit allerdings schon um etwa 1/4 zugenommen. Die einzelnen Automatendefinition sind (in verschiedenen Dimensionen) sehr viel größer als die Kanäle anderer Module, insofern werden und müssen wir da genauer abwägen wo eine Integration sinnvoll ist. Ich hätte die Funktionalität natürlich auch gerne überall lokal in den Geräten drin und denke daher über verschiedene Ansätze nach wie man das am besten realisieren kann. Später wider ausbauen wollen wir auf jeden Fall vermeiden.

[coko]

Ja, so ein kleineres State-Engine Modul ist an vielen Stellen sinnvoll. Statt im Presence dann langfristig sicher noch eher im Sensormodul (beinhaltet ja das Presence Modul). Aber auch im Zusammenspiel mit VirtualButton passt das sehr gut (z.B. für Szenen/Audio Steuerung mit älteren Tastern).

OAM-PresenceModule bildet in der Tat fast* eine Teilmenge von OAM-SensorModule ab, ist aber aktuell auch nach verschiedenen Meßgrößen die größte veröffentlichte ETS-Applikation. (Die nur intern getestete "große StateEngine" war noch größer, aber die damit gesammelten Erfahrungen sprachen letztendlich gegen die Veröffentlichung.)

Z.B. 4 Zustandsautomaten-Kanälen im Sensor-Modul (die ich auch gerne drin hätte) würden geschätzt zu einer Vergößerung um etwa 20% führen, bei längerfristiger Betrachtung werden die anderen enthaltenen Module durch die bereits geplante Features allerdings auch noch weiter wachsen.

* Das PresenceModule ist noch mit OFM-UsbExchange und OFM-Network verfügbar

[coko]

Video von Torben Ledermann über den OpenKNX Zustandsautomaten (inkl. Anwendungsbeispiel mit Erklärungen)
https://youtu.be/9Wlhuo1d-NI?feature=shared

noch einige einige Tipps und Tricks veröffentlichen, passend zum Beispiel im Video.

Hier nun die angekündigten Tipps und Tricks basierend auf dem Video (Dinge die nicht so offensichtlich sind oder noch nicht oder nicht so prominent in der Dokumentation auftauchen):

• Benennung der Eingabesymbole: Die sollte möglichst kurze Wörter verwenden, da durch die Tabellendarstellung sonst unschöne Umbrüche erfolgen (die man auf der Seite mit der Eingabe allerdings noch nicht sieht).
  • Sollte ich da womöglich noch einen zusätzlichen Hinweis anbringen? Häufige Nutzer werden es wahrscheinlich irgendwann automatisch entsprechend machen.
• Erleichterte Eingabe von Folgezuständen: Über die Tastatur kann direkt die Zustandsnummer eingegeben werden. Mit <Tab> kann zum nächsten Eingabe gewechselt werden.
• Erleichterte Eingabe des Sendeverhaltens:
  • Über die Tasten-,k(kein Senden),w(Wert),z(Zustand),j(jedes) kann die jeweilige Sendestrategie schnell ausgewählt,bzw.zwischen den verschiedenen Ausprägungen gewechselt,werden. Mit <Tab> kann zum nächsten Zustand gewechselt werden.
  • Durch Mehrfach-Auswahl (mit Strg-Taste) kann das Sendeverhalten gleichzeitig für mehrere Ausgänge gesetzt werden, da häufig in den selben Zuständen gesendet werden soll
• Startverhalten: Als Startzustand es es häufig nützlich erst mal einen neutralen Zustand zu nutzen, der keine Auswirkungen hat, bzw. durch die Ausgangswerte erst einmal einen "sicheren" Zustand animmt. Zumindest sollte man dort eine bewusste Definition vornehmen, mit Berücksichtigung dass ein Neustart ggf. auch nach Stromausfall in Abwesenheit erfolgen kann.
  • Im gezeigten Beispiel würde immer 1s nach Neustart des Geräts die Party-Szene aufgerufen, sofern man nicht zufällig zwischendurch noch eine Taste drückt.
  • Sofern kein eindeutiges Verhalten nach einem Neustart existiert, definiere ich daher i.d.R. einen Zustand "undefiniert" der erst mal nichts tut außer zu warten bis durch ein Ereignis zu einem passenden Zustand gewechselt werden kann. Falls Warnzustände existieren, dann bietet es sich auch an nach einer gewissen (nicht zu langen Verzögerungen) in den schlimmsten Warnzustand zu wechseln um zu verhindern, dass Warnungen verschluckt werden
• Ausgabewerte für einzelne Zustände weglassen (warum das problematisch ist): Wird für einen Zustand kein Ausgangswert festgelegt, so bleibt der letzte Wert auf dem KO erhalten. D.h.: Bei wiederholtem Aufruf des selben Zustands habe ich nicht immer den selben Ausgangswert. Das ist ungünstig weil damit eine klare Abhängigkeit des Ausgangswertes vom Zustand fehlt. Bei Zuständen nicht automatisch (nach kurzer Zeit) verlassen werden ist das intransparent, wenn der Ausgangswert nun davon abhängt welcher oder welche Zustände vorher aktiv waren. Bei direktem Aufruf von Zuständen ist das Verhalten auch nur noch schwer nachvollziehbar. Ein vollmüllen des Busses mit unveränderten Werden kann durch das Sendeverhalten vermieden werden. Es schadet also in keiner Weise wenn man unveränderte Ausgangswerte mehreren Zuständen zuweist.
  • Im gezeigten Beispiel wird im Zwischenzustand keine Szene gesendet (da passt es), der Ausgangstext sollte aber in solchen Fällen besser im Zwischen und Endzustand angegeben werden. Damit ist das Verhalten auch bei späteren Erweiterungen stabil in denen ein Endzustand direkt aufgerufen würde.

[coko]

Da der Einstieg in die Nutzung des Moduls Zustandsautomaten und der State-Engine tendenziell nicht so leicht fällt, vor allem wenn man vorher noch nie mit Automatendefinitionen zu tun hatte, würde ich zur Unterstützung mal einen Einführungstermin/-workshop anbieten.

Mögliche Inhalte:

• Kurze Einführung in das Konzept von "Zustandsautomaten"
• Übersicht über das Modul
• Evtl. Vorstellen einzelner Beispiele
• Gemeinsame Modellierung von Automaten
• Hinweise, Empfehlungen und Tricks zur Modellierung

Bitte meldet Euch einfach mal hier, damit ich sehen kann ob da allgemeines Interesse besteht als Basis für eine weitere Planung. Am besten mit einem kurzen Hinweis zu Vorkenntnissen, Erwartungen an ein solches Format und ggf. angetrebten Einsatzszenarien.

Bereits Interesse bekundet hatten: Stereofeld Masifi
FYI: shortyle

[coko]

Zur Info für Abonnenten dieses Threads, da nachträgliche Änderungen ansonsten unsichtbar bleiben:

Ich habe nun begonnen die FAQ und Tipps zur Modellierung & Nutzung für die OpenKNX-StatEngine bzw. das Modul OpenKNX-Zustandsautomaten zu befüllen mit einigen gesammelten Beiträgen.

Auch die Liste der Anwendungsbeispiele für die OpenKNX-StatEngine bzw. das Modul OpenKNX-Zustandsautomaten habe ich nochmal um weitere Einträge ergänzt, die teilweise auch in anderen Threads veröffentlicht wurden. Die letzten Updates habe ich hervorgehoben.

[willisurf]

Ich möchte mal eine Anwendung beschreiben, bei der die Umschaltung von Audioquellen (Sonos) mit einem MDT Glastaster über den Zustandsautomaten gesteuert wird. Es ist eine sehr einfache Anwendung und wer das Video von Torben Ledermann gesehen hat, wird das Prinzip sofort wiedererkennen. In dieser Anwendung ist es jedoch noch um weitere Ausgänge zur Steuerung von Anzeigeicons und der Lautstärke erweitert.

Der MDT Glastaster bietet die Funktion "Werte senden" -> "Szenen umschalten (bis zu 4 Werte). Diese Funktion wird genutzt um Audioquellen mit einer Taste umzuschalten, dabei können über den Statuseingang bis zu 4 verschiedene Icons angezeigt werden. Gleichzeitig wird über einen dynamischen Text der Titel des Favoriten angezeigt. Dies ist besonders bei z.B. Spotify Playlisten sinnvoll, um trotz des gleichen Icons die Listen unterscheiden zu können. Eine sehr nützliche Funktion ist es pro Favorit die Lautstärke vorgeben zu können. So startet Hintergrundmusik automatisch leise und Metal wird laut gehört. Mit dem Zustandsautomaten lassen sich bis zu 8 Favoriten umschalten, das folgende Video zeigt die Implementierung mit 6 Favoriten und die grundsätzliche Funktionalität.

Der Radiosender N-Joy liegt auf Favorit 1, im ersten Teil des Videos werden über einen kurzen Tastendruck die 6 Favoriten durchgeschaltet. Nach 6 kommt wieder 1.
Wenn man danach beim Umschalten auf NDR Info unten auf die Anzeige Volume in% achtet, bleibt der Wert während des Umschaltens unverändert und erst wenn man länger als 1sec nicht gedrückt hat, wird auf den Sender und die passende Lautstärke umgeschaltet (bei NDR Info 26% bei 10s im Video).
Danach wird auf Metal mit 24% umgeschaltet (17s im Video).
Zu Abschluß zeigt das Video, das man von jeder Stelle mit einem Tastendruck auf Favorit 1 springen kann.
https://drive.google.com/file/d/13q3...sqYUwUOln/view

D.h. bei jedem Tastendruck hat man sofort eine Rückmeldung mit Icon und Textbeschreibung. Man kann so gezielt schnell zum gewünschten Favoriten springen, ohne das zwischendurch der Favorit oder die Lautstärke verändert wird. Erst nach 1s ohne Tastenbetätigung wird Audioquelle und passsende Lautstärke eingestellt.
Dies wird (wie bei Torben) dadurch erreicht, das es für jeden Favoriten zwei Zustände gibt. Einen Zustand vor... (States 1-6), in dem nur des Icon/Anzeigetext umgeschaltet wird und der nach 1s Timeout verlassen wird und dann in den endgültigen Zustand (States 7-12) springt. In diesem Zustand wird dann wirklich der Favorit/Volume gesendet. Die zustände sind so gewählt, damit ich von der Visualisierung (X1/G1) ebenfalls direkt die Favoriten steuern kann. Dazu wird der Zustand von außen über die Visualisierung direkt gesetzt.

image.pngHier noch die Definition der Ausgänge
Ausgang1 Playlist
image.png
Ausgang2 Volume
image.png
Ausgang3 Anzeigeicon
image.png
Ausgang4 Anzeigetext (muss Ausgang4 sein, nur dieser unterstützt DPT16)
image.png
Gesamtkonfiguration
image.png
Der String für Konfig-Transfer (Kanal7)

OpenKNX,cv1,0xAC0D:0x3/DFA:0x4/7§a~Name=AZ%20Sonos§a~Active=1§a~StateRestore=1§a~ StateSetting=1§a~StartupDelayTime=8§a~SymbolAName: 1=Taste%20kurz§a~SymbolAInput:1=1§a~SymbolBName=Ta ste%20lang§a~SymbolBInput=1§a~Output1Name=Playlist §a~Output2Name=Volume§a~Output3Name=Anzeigeicon§a~ Output4Name=Anzeigetext§a~Output1Dpt=171§a~Output2 Dpt=51§a~Output3Dpt=171§a~Output4Dpt=161§a~z01Name =vor%20N-Joy§a~z02Name=vor%20NDR%20Info§a~z03Name=vor%20Rad io§a~z04Name=vor%20Spotify%20Chillout§a~z05Name=vo r%20Spotify%20Metal%20Gothic§a~z06Name=vor%20Spoti fy%20Power%20Metal§a~z07Name=N-Joy§a~z08Name=NDR%20Info§a~z09Name=Radio§a~z10Name =Spotify%20Chillout§a~z11Name=Spotify%20Metal%20Go thic§a~z12Name=Spotify%20Power%20Metal§a~d01A=2§a~ d01B=7§a~d01T=7§a~d01TTime=1§a~z01o3Send=4§a~z01o4 Send=4§a~z01o4Dpt16=N-Joy§a~d02A=3§a~d02B=7§a~d02T=8§a~d02TTime=1§a~z02o 3Send=4§a~z02o4Send=4§a~z02o4Dpt16=NDR%20Info§a~d0 3A=4§a~d03B=7§a~d03T=9§a~d03TTime=1§a~z03o3Send=4§ a~z03o4Send=4§a~z03o4Dpt16=INetRadio§a~d04A=5§a~d0 4B=7§a~d04T=10§a~d04TTime=1§a~z04o3Send=4§a~z04o4S end=4§a~z04o4Dpt16=Chillout§a~d05A=6§a~d05B=7§a~d0 5T=11§a~d05TTime=1§a~z05o3Send=4§a~z05o3Dpt17=3§a~ z05o4Send=4§a~z05o4Dpt16=Metal§a~d06A=1§a~d06B=7§a ~d06T=12§a~d06TTime=1§a~z06o3Send=4§a~z06o3Dpt17=3 §a~z06o4Send=4§a~z06o4Dpt16=Power§a~d07A=2§a~z07o1 Send=10§a~z07o1Dpt17=0§a~z07o2Send=4§a~z07o2Dpt500 1=20§a~d08A=3§a~d08B=7§a~z08o1Send=10§a~z08o1Dpt17 =1§a~z08o2Send=4§a~z08o2Dpt5001=26§a~d09A=4§a~d09B =7§a~z09o1Send=10§a~z09o1Dpt17=2§a~z09o2Send=4§a~z 09o2Dpt5001=12§a~d10A=5§a~d10B=7§a~z10o1Send=10§a~ z10o1Dpt17=3§a~z10o2Send=4§a~z10o2Dpt5001=12§a~d11 A=6§a~d11B=7§a~z11o1Send=10§a~z11o1Dpt17=4§a~z11o2 Send=4§a~z11o2Dpt5001=24§a~d12A=1§a~d12B=7§a~z12o1 Send=10§a~z12o1Dpt17=5§a~z12o2Send=4§a~z12o2Dpt500 1=20§;OpenKNX

Die Taste kurz wird über einen Logikkanal erzeugt. Der Glastaster sendet eine Szene (1-4) und die Logik erzeugt aus jeder Szene einfach den boolschen Wert true

Der String für Konfig-Transfer (Kanal27)

OpenKNX,cv1,0xAC0D:0x3/LOG:0x35/27§f~Name=DEA6%20Taste%20kurz%20Gast§f~ChannelDela yTime=5§f~Logic=2§f~Calculate=1§f~NameInput1=AZ%20 Taster%20Szene%20Gast§f~E1=1§f~E1Dpt=9§f~E1Low0Dpt 17=1§f~E1Low1Dpt17=2§f~E1Low2Dpt17=3§f~E1Low3Dpt17 =4§f~NameOutput=DEA6%20Taste%20kurz%20Gast§f~OOff= 0§f~OOffAll=0§;OpenKNX

Kurz noch die Konfiguration des MDT Glastasters
image.png

[coko]

willisurf vielen Dank für das schöne Beispiel, inkl. Video!

Die zustände sind so gewählt, damit ich von der Visualisierung (X1/G1) ebenfalls direkt die Favoriten steuern kann. Dazu wird der Zustand von außen über die Visualisierung direkt gesetzt.

Rufst Du dann Zustand 1 bis 6, oder Zustand 7 bis 12 auf?

Bei 7 bis 12 würde noch der alte Text (O4) und das alte Icon (O3) stehen bleiben, sofern diese nicht noch anderweitig (X1?) gesetzt werden. Gleiches würde ich auch erwarten beim Direktaufruf durch langen Tastendruck. Ich hätte die Ausgangswerte für O3 und O4 in allen Zuständen definiert, ggf. mit Reduktion der Sendestrategie auf Wert-Änderung + Rekonstruktion.

[willisurf]

Rufst Du dann Zustand 1 bis 6, oder Zustand 7 bis 12 auf?

Bei Aufruf über die Visu ist es die normale Szene 1-6, von daher passt die Anzeige dann (auch wenn man dann nicht auf den Taster schaut.

Gleiches würde ich auch erwarten beim Direktaufruf durch langen Tastendruck. Ich hätte die Ausgangswerte für O3 und O4 in allen Zuständen definiert, ggf. mit Reduktion der Sendestrategie auf Wert-Änderung + Rekonstruktion.

Ja, das ist eine gute Idee, bei langem Tastendruck würde sonst das Icon/Text erst nach 1s aktualisiert.
Werde ich mir anschauen und ändern. Dankeschön!

[coko]

Bei Aufruf über die Visu ist es die normale Szene 1-6, von daher passt die Anzeige dann (auch wenn man dann nicht auf den Taster schaut.

Ok, dann wartest Du dort also auch noch mal 1s.

Ja, das ist eine gute Idee, bei langem Tastendruck würde sonst das Icon/Text erst nach 1s aktualisiert.

Bei langem Tastendruck wechselst Du doch (in der Konfiguration aus den Screenshots) direkt in in Zustand 7, der hat keinen Timeout und keine Wert für O3 und O4. Alternativ könntest Du stattdessen in Zustand 1 wechseln, wobei dann noch 1s warten folgt.

[willisurf]

Ok, dann wartest Du dort also auch noch mal 1s.

Ja, ist durchaus beabsichtigt

Alternativ könntest Du stattdessen in Zustand 1 wechseln, wobei dann noch 1s warten folgt.

Genau, ich probiere das mal beides aus. Das ist ja der Vorteil des DEA, das man so einfach und übersichtlich ändern kann.

[coko]

Die Taste kurz wird über einen Logikkanal erzeugt. Der Glastaster sendet eine Szene (1-4) und die Logik erzeugt aus jeder Szene einfach den boolschen Wert true

Hat das eigentlich einen besonderen Grund, warum Du die Verknüpfung hier über KO umgesetzt hast und nicht direkt mit dem Logikkanal verknüpft hast? (Beim Import müsste man dort dann natürlich aufpassen, wenn der Logikkanal nicht an der selben Stelle importiert wird) Wahrscheinlich zum Debuggen?

[willisurf]

Ja genau, ist noch vom Entwickeln übrig.

[coko]

Service-Hinweis: Das Senden mit DPT9 und DPT14 funktioniert nicht korrekt ( willisurf hat den Fehler entdeckt, Danke) und schreibt fehlerhafte Werte auf den Bus. Ursache ist bereits identifiziert.

Nach weiterer Analyse könnten auch Fehler bei DPT8 und DPT13 auftreten, bei Werten die außerhalb des entsprechenden vorzeichenbehafteten Wertebereichs liegen.

Möglicher Workaround: Ganzzahlausgabe nutzen (mit Werten ohne das oberste Bit) und mit Logikkanal in DPT9 konvertieren. Das sollte zur Sicherheit für alle verwendeten Eingabewerte einmal geprüft werden.

Update folgt.