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.