OpenKNX StateEngine: Universelle Zustandsautomaten in KNX

[coko]

sewi erst mal vielen Dank, dass Du Dein Beispiel hier veröffentlicht, inkl ConfigTransfer-String!

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

So exotisch ist der Anwendungsfall gar nicht. Ich erinnert mich dunkel an eine Diskussion im Forum mit änhlicher Zielsetzung. Falls ich die wiederfinden, würde ich die noch mal verlinkten.

Habe Deine Beispiel bislang nur in Textform überflogen, aber schon erste Anmerkungen/Anregungen/Ideen zur Diskussion:

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.

Da könnte die Nutzung eines bedingten Startzustands interessant sein, um den passenden Startzustand, ohne warten auf passende Ereignisse, zu ermitteln. (Wobei das ein Szenario ist, welches von einem bisher nicht implementierten ELSE mit weiteren Sprüngen profitieren würde)

[Alloc]

So exotisch ist der Anwendungsfall gar nicht. Ich erinnert mich dunkel an eine Diskussion im Forum mit änhlicher Zielsetzung. Falls ich die wiederfinden, würde ich die noch mal verlinkten.

Der hier?
Wobei ich (nicht zuletzt auf Grund der vielen Lichtkanäle, aber auch weil es ohne FSM für uns gut genug geht) inzwischen wieder nur einen einzelnen Logikkanal pro Lichtkanal verwende.

[sewi]

Da könnte die Nutzung eines bedingten Startzustands interessant sein, um den passenden Startzustand, ohne warten auf passende Ereignisse, zu ermitteln. (Wobei das ein Szenario ist, welches von einem bisher nicht implementierten ELSE mit weiteren Sprüngen profitieren würde)

Die habe ich mir kurz angesehen, aber da müsste ich wieder einen Logikkanal verwenden - ich wollte alles in den Zustandsautomaten packen ohne Abhängigkeit zu einem Logikkanal - irgendwie kommt mir das "sauberer" vor. So kannst das importieren (und ich kann es duplizieren, falls ich das in anderen Zimmern auch machen möchte) und es geht sofort.

Was ich probiert habe - um diese undefinierten Werte so kurz wie möglich zu halten - ist das Setzen des I-Flags für die zwei Eingang-KOs - denn eigentlich, wenn er den Präsenz- und Lichtstatus lesen kann, dann ist er innerhalb von Sekundenbruchteilen im richtigen Status. Das Lese-Request kommt auch, aber selbst wenn ich die Startzeit von dem Zustandsautomaten auf 0 Sekunden stelle, startet er anscheinend erst nachdem die Antwort empfangen wurde (im Monitor ist die Reihenfolge Lese-Request -> Antwort -> 100-200ms Pause - Automat sagt er ist im Zustand 1). Ist es möglich, das Lese-Request erst zu senden, nachdem der Zustandsautomat "gestartet" wurde (vor allem wenn er auf 0 Sekunden steht), oder ist dieses Verhalten so tief im KNX Stack drinnen dass man es nicht ändern kann?

[coko]

um diese undefinierten Werte so kurz wie möglich zu halten - ist das Setzen des I-Flags für die zwei Eingang-KOs - denn eigentlich, wenn er den Präsenz- und Lichtstatus lesen kann, dann ist er innerhalb von Sekundenbruchteilen im richtigen Status. Das Lese-Request kommt auch, aber selbst wenn ich die Startzeit von dem Zustandsautomaten auf 0 Sekunden stelle, [...] Ist es möglich, das Lese-Request erst zu senden, nachdem der Zustandsautomat "gestartet" wurde (vor allem wenn er auf 0 Sekunden steht), oder ist dieses Verhalten so tief im KNX Stack drinnen dass man es nicht ändern kann?

Das ist auf jeden kein Verhalten was in den Zustandsautomaten implementiert ist. Das Verhalten aus dem Stack ist soweit mir bekannt nicht in der OpenKNX-Zeit ergänzt worden, also wahrscheinlich schon älter und erfolg ggf. auch vor dem Start des OpenKNX-Teils (wo auch noch die Geräte-Startverzögerung mit greift) . Genaues Auslösen von Read-Requests könntest Du über einen Logikkanel machen.

[mumpf]

ich wollte alles in den Zustandsautomaten packen ohne Abhängigkeit zu einem Logikkanal - irgendwie kommt mir das "sauberer" vor.

Dem möchte ich widersprechen. Es tut mir leid, das so sagen zu müssen, aber StateEngine und Logiken gehören eng zusammen. Im Allgemeinen brauchst Du Logikkanäle, um die Trigger für die StateEngine vorzubereiten (DPT-Wandlung, Intervallprüfung, Filterung, einfache logische Ausdrücke, bedingte Startzustände, bedingte Zustandsübergänge). Wir haben hier wirklich viel getan, um mittels des Konfigurationstransfers auch die Vervielfältigung von Kanälen einfach zu ermöglichen. Wenn man etwas strukturiert arbeitet (oder es entsprechend dokumentiert), kann man gut Zusammenhangskomponenten bilden.

Wenn du es anders machen willst, steht Dir das natürlich frei, aber ich sehe bei uns keine wirkliche Lücke, um das zu erreichen, was Du eigentlich willst - Du willst es nur so nicht machen.

Was ich probiert habe - um diese undefinierten Werte so kurz wie möglich zu halten - ist das Setzen des I-Flags für die zwei Eingang-KOs - denn eigentlich, wenn er den Präsenz- und Lichtstatus lesen kann, dann ist er innerhalb von Sekundenbruchteilen im richtigen Status

Das I-Flag ist ein unausgereiftes Konzept, an der Applikation vorbei KO-Werte zu lesen. Unausgereift deswegen, weil es auf KNX-Stack-Level passiert, ohne Rücksicht auf den Zustand der Applikation und ohne Rücksicht auf den Zeitpunkt, wann man den Wert gebrauchen bzw. auswerten kann. Wir werten das nicht aus, erlauben stattdessen über da Logikmodul ein wesentlich feineres - frei einstellbares - Verhalten von GroupValueRead, abgesehen von den in vielen Applikationen angebotenen Einstellungen zum lesen von Eingängen.

Und ergänzend dazu noch meine Meinung zu den Eingängen der StateEngine (bezogen auf das "sauberer" oben): Da die StateEngine nur Event-Basiert funktioniert, sollten deren Eingänge gar nicht das A-Flag gesetzt haben (das habe ich coko bereits geschrieben), denn damit kann ein GruopValueRead zwischendurch mal einen ungewollten Zustandsübergang auslösen. Der Startzustand sollte - sofern er nicht konstant ist - über normale Logikauswertung "bedingt" erfolgen. Dann gibt es auch keine Seiteneffekte und keine Wartezeiten für die Initialisierung.

Gruß, Waldemar

[sewi]

Dem möchte ich widersprechen. Es tut mir leid, das so sagen zu müssen, aber StateEngine und Logiken gehören eng zusammen. Im Allgemeinen brauchst Du Logikkanäle, um die Trigger für die StateEngine vorzubereiten (DPT-Wandlung, Intervallprüfung, Filterung, einfache logische Ausdrücke, bedingte Startzustände, bedingte Zustandsübergänge). Wir haben hier wirklich viel getan, um mittels des Konfigurationstransfers auch die Vervielfältigung von Kanälen einfach zu ermöglichen. Wenn man etwas strukturiert arbeitet (oder es entsprechend dokumentiert), kann man gut Zusammenhangskomponenten bilden.

Wenn du es anders machen willst, steht Dir das natürlich frei, aber ich sehe bei uns keine wirkliche Lücke, um das zu erreichen, was Du eigentlich willst - Du willst es nur so nicht machen.

Ich habe das auch nicht als Lücke bezeichnet, und auch beim erneuten Lesen meines Textes verstehe ich nicht, wie du das impliziert hast. In meinen Fällen kann ich die Funktionalität in einer Komponente und einem Kanal abbilden, und das kommt mir einfach"sauberer" vor, weil:
- ich keine zweite Komponente einbinden muss - für mich erhöht das die Komplexität, da ich ab dann zwischen dem Zustandsautomaten und der Logik hin- und her navigieren muss, um ein "vollständiges" Bild zu bekommen.
- ich dir so den Zustandsautomaten spontan, mit dem Blick auf die entsprechende Seite in der ETS, mit einem Single-Pane-of-Glass aufzeichnen kann.
- das eigentlich ganz genau so auch in der Kontexthilfe steht, die man sieht, wenn man auf die bedingten Übergänge geht. Dort steht "Wichtig" in fetten Buchstaben, gefolgt von:

Bedingte Übergänge sollten nur nach sorgfältiger Abwägung benutzt werden. Die Erweiterung im Vergleich zum übersichtlichen DEA-Modell führt zu einer deutlichen Erhöhung der Komplexität und reduziert die Nachvollziehbarkeit, kann jedoch auch sehr nützlich sein, wenn damit z.B. eine Vervielfältigung aller Zustände vermieden werden kann.

Und bei so einem Satz denke ich kurz nach - also die angeregte "sorgfältige Abwägung" - und überlege, brauche ich das wirklich, möchte ich nur das übersichtliche DEA-Modell haben, oder eine deutliche Erhöhung der Komplexität und Reduktion der Nachvollziehbarzeit. In diesem Fall komme ich zu dem Schluss, nein, brauche ich nicht, und wenn die Initialisierungsphase ein Problem ist - das ist sie bei mir nicht, ich habe da nicht einen Zustandsautomaten zusammengeklickt und in sofort ins Internet gepostet, das Ding läuft bei mir schon seit Monaten - kann man immer noch zwei Logik-Kanäle verwenden, damit der Wert schnell initialisiert wird. Dann ist der gleich in einem der unteren Zustände, und ist aber - für den Fall des Falles - trotzdem noch unabhängig von der Logik.

Das I-Flag ist ein unausgereiftes Konzept, an der Applikation vorbei KO-Werte zu lesen. Unausgereift deswegen, weil es auf KNX-Stack-Level passiert, ohne Rücksicht auf den Zustand der Applikation und ohne Rücksicht auf den Zeitpunkt, wann man den Wert gebrauchen bzw. auswerten kann.

Wie bereits gesagt, bin ich nicht tief genug in der Materie um zu wissen, welcher Teil in euren Geräten sich nun um den I-Flag kümmert, ob es nun der kleine KNX-Chip auf der MCU ist, oder eine der Libs ist, die ihr verwendet, oder das Programm selbst. Wüsste ich es, so müsste ich nicht fragen. Es war nur ein Vorschlag, und wenn er nicht realistisch ist, dann eben nicht.

[coko]

Da die StateEngine nur Event-Basiert funktioniert, sollten deren Eingänge gar nicht das A-Flag gesetzt haben (das habe ich coko bereits geschrieben), denn damit kann ein GruopValueRead zwischendurch mal einen ungewollten Zustandsübergang auslösen.

Das ist fürs nächste Release auch schon vorgesehen und vorbereitet. Beschränkt sich allerdings nicht nur auf die Symbol-Eingänge, sondern wird auch fürs Setzen vom Zustand mit angepasst...

Das I-Flag ist ein unausgereiftes Konzept, an der Applikation vorbei KO-Werte zu lesen. Unausgereift deswegen, weil es auf KNX-Stack-Level passiert, ohne Rücksicht auf den Zustand der Applikation und ohne Rücksicht auf den Zeitpunkt, wann man den Wert gebrauchen bzw. auswerten kann. Wir werten das nicht aus, erlauben stattdessen über da Logikmodul ein wesentlich feineres - frei einstellbares - Verhalten von GroupValueRead, abgesehen von den in vielen Applikationen angebotenen Einstellungen zum lesen von Eingängen.

Ich habe kurzfristrig leider keine Aussage dazu gefunden, ob die KNX-Spec Forderungen zum Zeitverhalten das Init-Flags stellt. Annahme: Es sollte erlaubt sein, die Initialisierung auch zu verzögern, mindestens global auf Geräteebene. Bei individueller Verzögerung würde ich das schon weniger kritisch sehen, wobei es dann immer noch aus Konfigurationssicht sehr unglücklich ist, weil in der ETS keine Verbindung zwischen Flag und Parametern abgebildet ist (bzw. nur einseitung möglich wäre mit Verlust der GA-Verknüpfung) und somit eine konsistente Konfiguration scheitert.

welcher Teil in euren Geräten sich nun um den I-Flag kümmert, ob es nun der kleine KNX-Chip auf der MCU ist, oder eine der Libs ist, die ihr verwendet, oder das Programm selbst.

Macht der KNX-Stack seit 2019 und zwar für alle KOs mit dem entsprechenden Flag am Stück, sofern nach Erzeugen der KOs: https://github.com/OpenKNX/knx/blame....cpp#L105-L118
Ohne Berücksichtigung einer möglichen eingestellten Startverzögerung des Gerätes. Mit der aktuellen Implementierung würde ich nach dem ersten Eindruck eher davon absehen das I-Flag bei OpenKNX-Geräten (und ggf. auch anderen auf dem zugrunde liegenden Basis-Stack) zu verwenden.

[mumpf]

sewi: Sorry falls das falsch rüberkam, ich wollte nur sagen: Du willst das so, dann mach das so.

Da aber immer auch andere mitlesen, wollte ich das

irgendwie kommt mir das "sauberer" vor

so nicht stehen lassen. Logiken und Zustandsautomaten gehören eng zusammen und es ist nichts unsauberes dran, beide gemeinsam zu verwenden.

Gruß, Waldemar

[mumpf]

sewi: Um zu zeigen, dass ich solche Diskussionen auch wirklich sachlich betrachte:
Wir haben - angeregt durch Deine Versuche mit dem I-Flag - nochmal intern diskutiert. Wir werden das nicht unterstützen (weil wir bessere Möglichkeiten bieten), aber wir wollen möglichst auch User unterstützen. Wir haben eine Möglichkeit gefunden, das I-Flag für unsere Applikationen in der ETS nicht aktivierbar darzustellen, und das auch noch update-kompatibel. In der nächsten größeren Release-Welle wird man also direkt im UI sehen, dass wir das I-Flag nicht unterstüzten.
Danke für den Beitrag und die Diskussion,
Waldemar