[Implemented] Universeller Zustandsautomat

[Dragonos2000]

Im KNXUF hatten wir's vor einiger Zeit schonmal, ich bring's aber hier nochmal auf- als zentraler Sammelpunkt für Feature Requests
Wie der Titel schon sagt: Zustandsautomat

Also:
-Beliebige definierbare Kriterien,um in einen Zustand zu wechseln
-Definierbarer hold-down Timer, während dem ein Kriterium kontinuierlich erfüllt sein muss, um in einen Zustand zu wechseln
-Zyklisches oder einmaliges ausführen von Aktion, solange sich der Automat im jeweiligen Zustand befindet
-Beliebige definierbare Kriterien,um in einen Zustand verlassen zu können
-Definierbare Mindesthaltedauer, um in einen Zustand verlassen zu können
-Abfragemöglichkeit, in welchem Zustand sich der Automat gerade befindet und Status der Timer

Kriterien könnten z.B. sein:
-Sonnenstand (Winkel, Höhe,...)
-Uhrzeit/Datum
-Temperatur
-Helligkeit
-Binär
-Hold-Down und Haltetimer
-Int Zahlenwerte
-Feuchtigkeit
-Windgeschwindigkeit
-Interne Zustände des TW
-...

[Dragonos2000]

Weitere Ideen:
-Möglichkeit, den Automaten zu deaktivieren (Sperrobjekt), auf Wunsch mit autom. Rückfall nach einer einstellbaren Zeit
-Zusätzliche Aktion je Zustand, die beim Eintreten oder Verlassen des Zustands einmalig ausgeführt wird
-Eventgesteuert (bei Wertänderung der Kriterien) und/oder Timergesteuert (zyklisches abarbeiten), sowie separates Triggerobjekt
-Möglichkeit, den Automaten direkt in einen Zustand zu versetzen (bspw. per KNX Telegramm oder Visu)

[Dragonos2000]

Wow, was für ein Deutsch in meinem Initialen Post. Ist ja mega peinlich Man möge mir die Schreibfehler verzeihen, ich kann es leider nicht mehr korrigieren

[Chris M.]

Der ist wirklich wichtig. Deshalb hatte ich ja den beim WireGate als Plugin bereitgestellt

[StefanW]

Wir denken darüber nach. Der größte Aufwand liegt im Editor dafür, aber vielleicht brauchen wir noch eine zündende Idee, wie das grafisch aussehen kann

Stefan

[Dragonos2000]

Danke
Ist halt ein wirklich mächtiges Werkzeug.
Euch ne zündende Idee beizusteuern ist schwierig, wenn man die Oberfläche nicht kennt. Ich pinsel mal was ins Blaue nach dem Motto "grüne Wiese" und "wünsch' Dir was". Vielleicht reicht es für einen Anstoß...

Hinzugefügt nach 26 Minuten 57 Sekunden:
Ich würd's mir vorstellen wie in der Zeichnung, unte der Annahme dass Ihr ne drag'n drop Oberfläche habt.
Es wird ein Zustandsobjekt reingezogen, das prinzipell 4 Datenbereiche hat:
-Eingangskriterien
-Aktionen
-Ausgangskriterien
-Ausgangsaktion

In die Datenbereiche können dann Felder gezogen werden für die jeweiligen Kriterien, deren Eigenschaften dann per Klick verändert werden können. Das ganze wird immer Sequenziell abgearbeitet, der erste passende Zustand "zieht".

[Chris M.]

Wir denken darüber nach. Der größte Aufwand liegt im Editor dafür, aber vielleicht brauchen wir noch eine zündende Idee, wie das grafisch aussehen kann

Na mehr oder weniger so wie es jeder macht, der einen Zustandsautomaten malt. Bilder-Google mal nach "stateflow".

Oder meinst Du nicht-graphisch?
* Tabelle/Liste mit n Zuständen (Name)
* Für jeden Zustand eine Aktion für's Betreten und eine weitere für's Verlassen
* Weitere Tabelle (n*n), die die Bedingungen enthält um von einem zu einem anderen Zustand wechseln zu können

Schau mal mein Zustands-Plugin an. Das macht nicht mehr als die Infrastruktur dafür bereit zu stellen.

[supernode]

Sollte es mehr tabellarisch werden hatten wir ja das Thema FSM/LUT im KNX UF auch schon diskutiert. Damit lassen sich so einfache State-Machines ja auch realisieren. Meiner Meinung nach oft auch übersichtlicher als graphisch.

Man stelle sich eine zweigeteilte Tabelle vor:
- Links: Eingänge mit Filterbedingungen, z.B: TemperaturA im Bereich [10 ..24] ; Feuchtigkeit > 5%, periodischer Timer-Puls, ein X für Don't Care
- Rechts: vorgegebene Werte der Ausgänge, z.B: fester Wert, Increment/Decrement des Eingangswertes, keine Wertänderung

Jede Zeile ist dann ein Fall. Ändert sich ein Eingang (Zustandsänderung, Event) so wird von oben her die erste Zeile gesucht für die Eingangskombination passt und dann die Ausgänge zugewiesen.

Eine FSM könnte dann mit einem Rückgekoppelten STATE-Ein-/Ausgang realisiert werden. States wären dann einfach Strings. Wenn dieser dann zyklisch aufgerufen wird ließen sich auch einfach Wartezeiten realisieren. Im KNX UF hatte ich schon mehr dazu geschireben. Vielleicht kann Stefan das ja noch einfließen lassen.

Noch kurz ein Beispiel:
- Inputs: RESET, STATE, IN1, IN2
- Outputs: STATE, OUT

Tabelle:
Zeile 1: RESET = 1, STATE = X, IN1 = X, IN2 = X || STATE = "start", OUT = 0
Zeile 2: RESET = 0, STATE = "start", IN1 = X, IN2 = X || STATE = "active", OUT = 1
Zeile 3: RESET = 0, STATE = "active", IN1 = 1, IN2 = 1 || STATE = no change, OUT = 0
Zeile 4: RESET = 0, STATE = "active", IN1 = 0, IN2 = 1 || STATE = no change, OUT = NOT(IN2)


Auch einfache Werte-Filter lassen sich so realisieren. Das mag vielleicht einfacher und übersichtlicher sein als wenn man mehrere Vergleicherglieder zusammenklickt.

[Dragonos2000]

Da bin ich bei Dir, dass es tabellarisch/gescripted einfacher und evtl. auch übersichtlicher zu implementieren ist. Aber so wie ich das aus Stefan's Beschreibungen und Äußerungen einschätze, sind sie beim TW eher grafisch unterwegs- für weniger versierte Anwender.

[supernode]

Im KNX UF hatte ich das damals anders herum verstanden. Wie dem auch sei, eine Möglichkeit einen Zustandsautomaten zu realisieren bräuchte man. Dabei sollte man auf jeden Fall auch auf das Debugging achten, d.h. Breakpoints auf einzelne Zustände oder eben Zeilen im obigen Beispiel setzen und schrittweise ausführen.

Im obigen Beispiel fehlt noch der ELSE-Zweig als letzte Zeile die ausgeführt wird wenn sonst nix greift.
Ebenso müsste man einen periodisch Aufruf des Zustandsautomaten ermöglichen, so dass er bspw. einfach alle 10 Sekunden den aktuellen State durchläuft. Längere dynamische Wartezeiten ließen sich dann über einen Rückgeschleiften Dezimalzähler realisieren.