Endlicher Automat (finite state maschine)

[Damian]

Ich überlege eine vereinfachte Syntax in DOIF einzubauen, mit der sich ein endlicher Automat (EA) einfach realisieren lässt.

Man kann jetzt schon einen EA mit DOIF wie folgt realisieren:

Code Auswählen Erweitern

DOIF (<Bedingung1> and [?<mein_doif>] eq "cmd_1") (<tue das>)
DOELSEIF (<Bedingung2> and [?<mein_doif>] eq "cmd_2") (<tue jenes>)
DOELSEIF ...

Die Abfrage des eigenen Status ist recht aufwändig. Meine Überlegung ist den eigenen Status statt mit:

Code Auswählen Erweitern


... and [?<mein_doif>] eq "cmd_1")

z. B. mit

Code Auswählen Erweitern


... and [?1])

abzufragen.

Dann dürfte es allerdings keine Definition in FHEM mit dem Namen "1" geben, was vermutlich unproblematisch ist.


Man könnte auch statt [?1] auch [$1] definieren.

Vielleicht hat jemand noch bessere Vorschläge für die abkürzende Schreibweise einer solchen Abfrage.

Edit: Für Abfragen nach Zwischenzuständen z. B. cmd_1_1 würde man dann logischerweise [?1_1] angeben können.

Gruß

Damian

[Ellert]

Für $ würde sprechen, dass es als $elf gelesen werden könnte. Kann es einen Konflikt mit den speziellen Regexp-Variablen  $1 usw. geben?

In diesem Zusammenhang könnte es auch praktisch sein ein Attribut "modifyState" zu haben, dass nach einem modify_<doifname> einen Status vorgibt, statt "initialized".

Es könnte auch interessant sein Eigentriggerung zu zulassen. Für solche Konstrukte:

Code Auswählen Erweitern

([$3] and ![Stop]) (...)
DOELSEIF ([$1]) (...)
DOELSEIF ([$2]) (...)

wait 10:10:10
selftrigger $3:$1:$2
modifyState cmd_3

Das DOIF läuft im Kreis bis [Stop] wahr wird, zB. für ein Lauflicht. Dann hätte man eine Art senkrechtes "repeatcmd".

[justme1968]

wäre es nicht besser dafür ein eigenes modul zu bauen statt es auch noch in die DOIF syntax zu pressen?

ich hatte mit einem solchen modul angefangen bin aber noch nicht dazu gekommen es hier vorzustellen. die syntax bei mir schaut etwa so aus:

Code Auswählen Erweitern

#define <sm> stateMachine CUL_HM_HM_PB_2_WM55_2B63C7_Btn_01,CUL_HM_HM_PB_2_WM55_2B63C7_Btn_02 Sonos_Esszimmer
attr <sm> transitions \
{ OFF => [ { event => '$1:Short', action => 'set $TARGET Volume 15; set $TARGET Play', newState => 'ON'  }, ], \
  ON  => [ { event => '$2:Short', action => 'set $TARGET Stop',                        newState => 'OFF' },    \
           { event => '$1:Long',  action => 'set $TARGET VolumeU',                     newState => 'ON'  },    \
           { event => '$2:Long',  action => 'set $TARGET VolumeD',                     newState => 'ON'  }, ], \
}
attr <sm> start OFF

define <sm> stateMachine CUL_HM_HM_PB_2_WM55_2B63C7_Btn_01,CUL_HM_HM_PB_2_WM55_2B63C7_Btn_02 Sonos_Esszimmer
attr <sm> stateFn {return 'OFF' if(ReadingsVal($TARGET,'transportState','STOPPED') eq 'STOPPED'); return 'ON'}
attr <sm> transitions \
{ OFF => [ { event =>   ':Short', action => 'set $TARGET Volume 15;; set $TARGET on', newState => 'ON'  }, ], \
  ON  => [ { event => '$1:Short', action => 'set $TARGET VolumeU', timeout => 0.5,    newState => 'ON'  },    \
           { event => '$1:Short', action => 'set $TARGET Volume 15',                  newState => 'ON'  },    \
           { event => '$2:Short', action => 'set $TARGET Stop',                       newState => 'OFF' },    \
           { event => '$1:Long',  action => 'set $TARGET VolumeU',                    newState => 'ON'  },    \
           { event => '$2:Long',  action => 'set $TARGET VolumeD',                    newState => 'ON'  }, ], \
}
attr <sm> start OFF

define <sm> stateMachine CUL_HM_HM_PB_2_WM55_2_25EBC7_Btn_01,CUL_HM_HM_PB_2_WM55_2_25EBC7_Btn_02 LED2_3
attr <sm> transitions \
{ OFF     => [ { event => '$1:Short|Long', action => 'set $TARGET on',      newState => 'ON'      },                  \
               { event => '$2:Short',      action => 'set $TARGET 50%',     newState => 'ON'      }, ],               \
  ON      => [ { event => '$1:Short',      action => 'set $TARGET 100%',    newState => 'ON', timeout => 0.5,      }, \
               { event => '$2:Short',      action => 'set $TARGET off',     newState => 'OFF'     },                  \
               { event => '$1:Long',       action => 'set $TARGET dimUp',   newState => 'DIMUP'   },                  \
               { event => '$2:Long',       action => 'set $TARGET dimDown', newState => 'DIMDOWN' }, ],               \
  DIMUP   => [ { event =>   ':Long',       action => 'set $TARGET dimUp',   newState => 'DIMUP'   },                  \
               { event =>   ':Release',    action => '{Log 1, $EVENT}',     newState => 'ON'      }, ],               \
  DIMDOWN => [ { event =>   ':Long',       action => 'set $TARGET dimDown', newState => 'DIMDOWN' },                  \
               { event =>   ':Release',    action => '{Log 1, $EVENT}',     newState => 'ON'      }, ],               \
}
attr <sm> start OFF


die idee ist im define die devices anzugeben auf deren events reagiert werden soll und dann den start zustand, die übergänge und die aktionen in attribute zu packen.

gruss
  andre

[Damian]

Für $ würde sprechen, dass es als $elf gelesen werden könnte. Kann es einen Konflikt mit den speziellen Regexp-Variablen  $1 usw. geben?

In diesem Zusammenhang könnte es auch praktisch sein ein Attribut "modifyState" zu haben, dass nach einem modify_<doifname> einen Status vorgibt, statt "initialized".

Es könnte auch interessant sein Eigentriggerung zu zulassen. Für solche Konstrukte:

Code Auswählen Erweitern

([$3] and ![Stop]) (...)
DOELSEIF ([$1]) (...)
DOELSEIF ([$2]) (...)

wait 10:10:10
selftrigger $3:$1:$2
modifyState cmd_3

Das DOIF läuft im Kreis bis [Stop] wahr wird, zB. für ein Lauflicht. Dann hätte man eine Art senkrechtes "repeatcmd".

Die Selbsttriggerung in Verbindung mit wait ging immer schon. Ohne wait ist gefährlich, weil sich die Leute schnell mit einem Loop das System lahm legen würden.

[$1] wäre unproblematisch da es keine Devices mit $ gibt und Regex für Devices werden ja in Anführungszeichen angegeben.

Man könnte im Konzept des Moduls bleiben mit  [?$1] ohne Trigger und [$1] mit Trigger.

Gruß

Damian

[Damian]

wäre es nicht besser dafür ein eigenes modul zu bauen statt es auch noch in die DOIF syntax zu pressen?

ich hatte mit einem solchen modul angefangen bin aber noch nicht dazu gekommen es hier vorzustellen. die syntax bei mir schaut etwa so aus:

Code Auswählen Erweitern

#define <sm> stateMachine CUL_HM_HM_PB_2_WM55_2B63C7_Btn_01,CUL_HM_HM_PB_2_WM55_2B63C7_Btn_02 Sonos_Esszimmer
attr <sm> transitions \
{ OFF => [ { event => '$1:Short', action => 'set $TARGET Volume 15; set $TARGET Play', newState => 'ON'  }, ], \
  ON  => [ { event => '$2:Short', action => 'set $TARGET Stop',                        newState => 'OFF' },    \
           { event => '$1:Long',  action => 'set $TARGET VolumeU',                     newState => 'ON'  },    \
           { event => '$2:Long',  action => 'set $TARGET VolumeD',                     newState => 'ON'  }, ], \
}
attr <sm> start OFF

define <sm> stateMachine CUL_HM_HM_PB_2_WM55_2B63C7_Btn_01,CUL_HM_HM_PB_2_WM55_2B63C7_Btn_02 Sonos_Esszimmer
attr <sm> stateFn {return 'OFF' if(ReadingsVal($TARGET,'transportState','STOPPED') eq 'STOPPED'); return 'ON'}
attr <sm> transitions \
{ OFF => [ { event =>   ':Short', action => 'set $TARGET Volume 15;; set $TARGET on', newState => 'ON'  }, ], \
  ON  => [ { event => '$1:Short', action => 'set $TARGET VolumeU', timeout => 0.5,    newState => 'ON'  },    \
           { event => '$1:Short', action => 'set $TARGET Volume 15',                  newState => 'ON'  },    \
           { event => '$2:Short', action => 'set $TARGET Stop',                       newState => 'OFF' },    \
           { event => '$1:Long',  action => 'set $TARGET VolumeU',                    newState => 'ON'  },    \
           { event => '$2:Long',  action => 'set $TARGET VolumeD',                    newState => 'ON'  }, ], \
}
attr <sm> start OFF

define <sm> stateMachine CUL_HM_HM_PB_2_WM55_2_25EBC7_Btn_01,CUL_HM_HM_PB_2_WM55_2_25EBC7_Btn_02 LED2_3
attr <sm> transitions \
{ OFF     => [ { event => '$1:Short|Long', action => 'set $TARGET on',      newState => 'ON'      },                  \
               { event => '$2:Short',      action => 'set $TARGET 50%',     newState => 'ON'      }, ],               \
  ON      => [ { event => '$1:Short',      action => 'set $TARGET 100%',    newState => 'ON', timeout => 0.5,      }, \
               { event => '$2:Short',      action => 'set $TARGET off',     newState => 'OFF'     },                  \
               { event => '$1:Long',       action => 'set $TARGET dimUp',   newState => 'DIMUP'   },                  \
               { event => '$2:Long',       action => 'set $TARGET dimDown', newState => 'DIMDOWN' }, ],               \
  DIMUP   => [ { event =>   ':Long',       action => 'set $TARGET dimUp',   newState => 'DIMUP'   },                  \
               { event =>   ':Release',    action => '{Log 1, $EVENT}',     newState => 'ON'      }, ],               \
  DIMDOWN => [ { event =>   ':Long',       action => 'set $TARGET dimDown', newState => 'DIMDOWN' },                  \
               { event =>   ':Release',    action => '{Log 1, $EVENT}',     newState => 'ON'      }, ],               \
}
attr <sm> start OFF


die idee ist im define die devices anzugeben auf deren events reagiert werden soll und dann den start zustand, die übergänge und die aktionen in attribute zu packen.

gruss
  andre

ja, kann man sicherlich programmieren, wenn man die Zeit dazu hat. Die Idee das in DOIF einzubauen kam bei mir auf, als ich diverse Vorschläge insb. von Ellert dazu mit DOIF gesehen habe. So etwas in das Modul DOIF einzubauen wäre für mich relativ einfach - das würde ich in meiner knappen Freizeit noch hinbekommen.

Gruß

Damian

[ZeitlerW]

Hallo Damian,

wenn ich Dich richtig verstanden habe wäre dies ja auch eine generische Lösung für mein Problem hier: http://forum.fhem.de/index.php/topic,49022.0.html.

Und auch die Lösung von Ellert: http://forum.fhem.de/index.php/topic,49022.msg406915.html#msg406915

lG
Wolfgang

[Damian]

Hallo Damian,

wenn ich Dich richtig verstanden habe wäre dies ja auch eine generische Lösung für mein Problem hier: http://forum.fhem.de/index.php/topic,49022.0.html.

Und auch die Lösung von Ellert: http://forum.fhem.de/index.php/topic,49022.msg406915.html#msg406915

lG
Wolfgang

ja, es ist natürlich keine neue Funktionalität, sondern lediglich eine Vereinfachung in der Definition des Moduls.

Gruß

Damian

[Ralli]

Wichtig wäre, dass $1 nicht in Perl-Code-Fragmenten ausgewertet wird.

[Damian]

Wichtig wäre, dass $1 nicht in Perl-Code-Fragmenten ausgewertet wird.

Das sollte kein Problem sein: Alles innerhalb von eckigen Klammern ist DOIF-Welt, alles außerhalb dieser Klammern in der Bedingung ist Perl-Welt.

[crusader]

Hallo Damian,

State-Machines mit DOIF sind eine interessante Anwendung.

Wichtiger als die Vereinfachung der Syntax wäre aus meiner Sicht aber die einfache Ermittlung des Timer-states, denn das ist eigentlich ja ein separater Status.

Momentan müsste man dazu wohl den Wert von wait_timer parsen oder hab' ich da was übersehen ?

[Damian]

Hallo Damian,

State-Machines mit DOIF sind eine interessante Anwendung.

Wichtiger als die Vereinfachung der Syntax wäre aus meiner Sicht aber die einfache Ermittlung des Timer-states, denn das ist eigentlich ja ein separater Status.

Momentan müsste man dazu wohl den Wert von wait_timer parsen oder hab' ich da was übersehen ?

Kannst du mir ein konkretes Beispiel nennen?

[crusader]

Ich gehe einfach mal vom Entwurfsmechanismus einer state-machine aus:

State_1 -> Event_x -> neuer State_2
            -> Event_y -> neuer State_3
State_2 -> Event_x -> neuer State_4

Diesen Mechanismus kann man über die vorgeschlagenen state-Abfrage einfach verwirklichen.
Man möchte aber auch oft Timeouts als auslösenden state-Übergang definieren.
Also z.B.:

State_2 -> Timeout_t1 -> neuer State_5

über das wait-Attribut kann man zwar eine Aktion bei Timeout auslösen, jedoch ändert sich ja der state nach Ablauf des Timers nicht.
Beispiel Waschmaschine:

State_off               -> (power > 5) -> State_debounce
State_debounce    -> (power < 4) -> State_off
State_debounce    -> Timeout_t1  -> State_on

Edit:
Unvollständiges Beispiel. Es fehlt:

State_debounce   -> (power > 1000) -> State_power

[crusader]

Das Beispiel ist etwas wenig praxisnah.

Hier was konkretes:
Waschmaschine soll Fertigzustand mitteilen, falls mindestens 5 min power > 5W erkannt und danach 5 min power < 3W erkannt.

Lösung mit Zusatz-reading 'status':

Code Auswählen Erweitern

([test.power:P.Waschmaschine] > 5)
    (setreading ctrl.washer status wait)
    (setreading ctrl.washer status on)
DOELSEIF ([test.power:P.Waschmaschine] < 3 and [?ctrl.washer:status] eq "wait")
    (setreading ctrl.washer status off)
DOELSEIF ([test.power:P.Waschmaschine] < 3 and [?ctrl.washer:status] eq "on")
    (setreading ctrl.washer status ready)
    (say Waschmaschine ist fertig)

mit attr wait 0,300:0:300

Das Beispiel zeigt auch gleich die Lösung mit Verwendung von state. Der state wechselt nämlich nach Ablauf des Timers von cmd_1_1 auf cmd_1.
Die Lösung mit der vorgeschlagenen DOIF-Änderung könnte also so aussehen:

Code Auswählen Erweitern

([test.power:P.Waschmaschine] > 5)
    ()   #on   = 1
    ()   #wait = 1_1
DOELSEIF ([test.power:P.Waschmaschine] < 3 and [?1_1])
    ()  #off = 2
DOELSEIF ([test.power:P.Waschmaschine] < 3 and [?1] )
    (say Waschmaschine ist fertig)   #ready = 3


Die Waschmaschinen-Fraktion wird sich freuen.

Edit:
Ich finde die augenblickliche Syntax [?<mein_doif>] eq "cmd_1" aber nicht als derart monströs, dass da unbedingt die Einführung einer neuen Option erforderlich wäre.
Lästig daran ist nur, dass diese Konstruktion kein rename oder copy überlebt. Das gleiche gilt auch für Readings oder Attribute, die man in <mein_doif> schreiben will (s.o.).
Wäre es nicht praktischer, eine variable für <mein_doif> einzuführen ?

Vielleicht: $self oder $name

[Damian]

Edit:
Ich finde die augenblickliche Syntax [?<mein_doif>] eq "cmd_1" aber nicht als derart monströs, dass da unbedingt die Einführung einer neuen Option erforderlich wäre.
Lästig daran ist nur, dass diese Konstruktion kein rename oder copy überlebt. Das gleiche gilt auch für Readings oder Attribute, die man in <mein_doif> schreiben will (s.o.).
Wäre es nicht praktischer, eine variable für <mein_doif> einzuführen ?

Vielleicht: $self oder $name

ja, [$1] stünde für einen ganzen Vergleich und ist natürlich etwas neues, was jeder lernen muss. Dagegen würde [$this] eq "cmd_1" wohl jeder verstehen. Der Status kann allerdings auch durch state manipuliert sein. Daher wäre vielleicht ein weiteres Reading z. B. "mystate", im Modul, welches statt "cmd_1" nur "1", bei "cmd_1_1" nur "1_1" enthält, interessant. Dann könnte man z. B. realisieren

[$mystate] eq "1"  $mystate wäre dann [<mein_device>:mystate]

Daher ist es wichtig sich vorher Gedanken zu machen, bevor man etwas unwiderruflich einführt.

Gruß

Damian

[Ellert]

Daher ist es wichtig sich vorher Gedanken zu machen, bevor man etwas unwiderruflich einführt.

Manchmal hängen DOIFs auch zusammen, daher könnte eine DOIF übergreifende vereinfachte Syntax hilfreich sein.

Beispiel:
5 DOIF "di1 ... di5" steuern je ein Heizventil.
1 DOIF "diz" sammelt die Stati der 5 DOIF und steuert eine Gastherme.

Code Auswählen Erweitern

diz DOIF ([$di1:$1_2] or [$di2:$1_2] ...) (set Gastherme on)

Die Selbsttriggerung in Verbindung mit wait ging immer schon.

Das DOIF bleibt nach dem [start] trigger bei cmd_1 stehen. Hier solllte der Status triggern.

Code Auswählen Erweitern

di ([start] or [di] eq "cmd_3") ()
DOELSEIF ([di] eq "cmd_1") ()
DOELSEIF ([di] eq "cmd_2") ()

wait 10:10:10