vorschau: neues modul stateMachine

Begonnen von justme1968, 04 April 2016, 21:26:30

Vorheriges Thema - Nächstes Thema

justme1968

anbei eine vorschau auf ein neues modul stateMachine an dem ich gerade bastle...

das ganze ist im prinzip eine kombination aus notify, watchdog und sequence. da die dokumentation noch komplett fehlt  ein paar beispiele:

- ein hm taster zum ein und aus schalten und lautstärke ändern:#define <fsm> stateMachine CUL_HM_HM_PB_2_WM55_2B63C7_Btn_01,CUL_HM_HM_PB_2_WM55_2B63C7_Btn_02 Sonos_Esszimmer
attr <fsm> 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 <fsm> start OFF


-das gleiche mit ein paar funktionen mehr und dem bestimmen des aktuellen zustands aus dem device das gesteuert wird:
#define <fsm> stateMachine CUL_HM_HM_PB_2_WM55_2B63C7_Btn_01,CUL_HM_HM_PB_2_WM55_2B63C7_Btn_02 Sonos_Esszimmer
attr <fsm> stateFn {return 'OFF' if(ReadingsVal($TARGET,'transportState','STOPPED') eq 'STOPPED');; return 'ON'}
attr <fsm> 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 <fsm> start OFF


- ein hm taster zum licht schalten und dimmen:
#define <fsm> stateMachine CUL_HM_HM_PB_2_WM55_2_25EBC7_Btn_01,CUL_HM_HM_PB_2_WM55_2_25EBC7_Btn_02 LED2_3
attr <fsm> 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 <fsm> start OFF


was noch eingebaut werden soll sind zustandsübergänge beim ausbleiben von (bestimmten) events und timer gesteuerte zustandsübergänge bzw. aktionen.

damit sind dann auch dinge möglich wie kontinuierliches rauf und runter dimmen oder lautstärke ändern unabhängig vom zeitraster in dem ein taster long press sendet. d.h. beim drücken wird die aktualisierung mit einem internen timer in einem bestimmten zeitraster gestartet und beim loslassen gestoppt. egal wie viele events dazwischen kommen.


wer hätte interesse an einem solchen modul? welche features wären noch sinnvoll?

gruss
  andre

edit: 2016-04-07:
added onEnter&onExit
added retrigger
added empty event & timeout
endet condition
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rudolfkoenig

Zitatwer hätte interesse an einem solchen modul?
Alle, die mit FHEM Bier brauen wollen :)
remo hat das bei mir vor 6 Jahren bestellt, leider ist daraus nie was geworden.
Ich meine dazu braucht man noch:
- bei einem Event auch eine Bedingung pruefen zu koennen.
- nach einer bestimmten Zeit in einem anderen Zustand wechseln zu koennen, auch ohne Event.
- diese Zeit waehrend des Ablaufs modifizieren zu koennen (optional)

Ob man auch noch weitere Sachen braucht, werden wir sehen, wenn wir das testen, ich bin nicht wirklich Experte :)

P.S.:timeout habe ich noch nicht verstanden...

justme1968

das klingt spannend :)

- das prüfen einer bedienung geht jetzt schon indirekt in dem man für action die {} perl variante verwendet. mann kann hier auch den neuen zustand zurück geben.

vielleicht ist hierzu aber ein extra condition eintrag im hash besser. gute idee.


- ja. das ist das was oben mit
Zitatwas noch eingebaut werden soll sind zustandsübergänge beim ausbleiben von (bestimmten) events und timer gesteuerte zustandsübergänge bzw. aktionen.
gemeint habe.

- hast du dafür ein konkretes beispiel?

timeout hat was mit doppelt klicken zu tun bzw. damit kann man zwischen zwei einzelnen klicks und einem doppel klick unterscheiden. das ist aber noch nicht intuitiv :)
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

gandy

Zitat von: justme1968 am 04 April 2016, 21:26:30
wer hätte interesse an einem solchen modul? welche features wären noch sinnvoll?

Eine meiner ersten FHEM-Gehversuche war ein Modul für eine Statemachine, das zwar seinen Dienst tut, es aber nie auf einen veröffentlichungswürdigen Level geschafft hat. Mir fehlt die Zeit, es dahin zu bringen, aber vielleicht kann ich ein paar Ideen zu Deinem Modul beitragen:

Hauptsächlich verwende ich die Statemachine, um aus dem Energieverbrauch von Geräten (gemessen über EC3000) deren Zustand abzuleiten und mich dann z.B. von FHEM informieren zu lassen, wenn Geschirrspüler oder Waschmaschine fertig sind. Ein reines on/off aus einem fixen Threshold abgeleitet ist mir hier zu wenig. Auch andere Zustände lassen sich aus Sensorwerte ableiten, wie der Homestatus oder der Zustand der Bewohner nach dem Bierbrauen  ;)

Zur zuverlässigen Erkennung eines Zustandswechsel hat es sich bei den Haushaltsgeräten als notwendig erwiesen, angeben zu können, wie lange eine Bedingung erfüllt sein muss, um ein hinreichendes Kriterium für den Übergang zu sein. Beispiel aus der Konfiguration für die Waschmaschine (bitte nicht an der Syntax stören):

from OFF to TIMED_DELAY if{(0.5 <= $p1) and ($p1 <= 5)} for{25}
from OFF to ACTIVE if{$p1 > 5} for{20}
from TIMED_DELAY to ACTIVE if{$p1 > 5} for{20}
 
$p1 ist hier das Reading des Leistungsmessgeräts, dessen Events ausgewertet werden. Wenn es 25 Sekungen lang zwischen 0.5W und 5W bleibt, wird der Timer-Betrieb (TIMED_DELAY) erkannt (Verzögertes Starten des Waschvorgangs), ist der Verbauch für 20 Sekunden mehr als 5W, sartet der Waschvorgang (ACTIVE). Während diese Übergänge noch einfach zu erkennen sind, folgt der Verbrauch anderen manchen Zuständen komplexeren Mustern, hier wäre eine Möglichkeit zur Erkennung von allgemeineren Sequenzen vorteilhaft.

Für jeden der Zustände kann ich in meiner Statemachine Callback-Funktionen onenter und onleave definieren, zum Beispiel:

onleave OFF { fhem("attr PowerMeterGS event-on-update-reading power"); }
onenter OFF { fhem("attr PowerMeterGS event-on-update-reading 0"); }

Das ist nicht so flexibel wie action, könnte in Kombination damit aber den Code lesbarer machen.

Zusätzlich zum Auslösen von Aktionen habe ich meiner Statemachine die Möglichkeit gegeben, Berechnungen für readings anzustellen: So kann z.B. der Verbrauch und die Zeitdauer von Erreichen oder Verlassen eines Zustands bis zum Erreichen oder Verlassen eines anderen (oder des gleichen Zustands) ermittelt werden:

reading waschgang_verbrauch PowerMeterGS:consumption delta [ACTIVE]
reading waschgang_dauer     ::timestamp              delta [ACTIVE]
reading laufzeit_verbrauch  PowerMeterGS:consumption delta ]OFF[
reading laufzeit_dauer      ::timestamp              delta ]OFF[
reading standby_verbrauch   PowerMeterGS:consumption delta [OFF]

Die Klammerung für die States bezeichnet, ob Betreten oder Verlassen des Zustands ausschlaggebend ist. Damit die Berechnung korrekt sein kann, müssen die beteiligten ReadingValues immer dann zwischengespeichert werden, wenn ein Zustandswechel wahrscheinlich wird. Im obigen Beispiel wäre das für den Wechel OFF->ACTIVE dann der Fall, wenn $p1 das erste Mal über 5W steigt. Der Zustandswechsel selbst wird anerkannt, wenn die Bedingung 20s lang erfüllt bleibt, für die Berechnung ist aber ausschlaggebend, welchen Wert PowerMeterGS:consumption zu Beginn dieser 20s hatte.

Vielleicht ergeben sich daraus ja ein paar (zusätzliche) Diskussionsansätze.

Beste Grüße,
Andy.
fhem (svn) auf i5-4210U NUC
2x HMLAN, 19x HM-SEC-RHS, 15x HM-LC-Bl1PBU-FM, etc.
ODYS Neron Tablet / Android 4.2
Samsung Galaxy Tab 2 10.1N / Android 4.1.2
Samsung Galaxy Note / Android 6.0.1

justme1968

das klingt auch interessant. für meine spülmaschine reicht ein watchdog.

ich habe gerade timer basierte übergänge eingebaut. damit kann man glaube ich auch deine anwendung abdecken. mit zusätzlichen zuständen. vermutlich wäre es aber gut die event syntax etwas zu erweitern so das vergleiche direkt möglich sind statt sie über eine regex zusammen zu bauen.

die actions habe ich bis jetzt bewusst nur beim betreten eines zustands. aktionen beim verlassen habe ich bis jetzt über zusätzliche zustände umgesetzt. das wird natürlich bei mehr als ein paar zuständen unübersichtlich.

die prinzipielle frage ist ob man lieber mit mehr zuständen arbeitet und diese einfacher editierbar macht (vielleicht sogar grafisch) oder ob man dein einzelnen zuständen mehr möglichkeiten verpasst. ich bin hier noch unentschlossen.


meinst du es ist sinnvoll die statisik ins stateMachine modul einzubauen oder über ein allgemeineres modul wie statistics oder energyMonitor das nur die events zu den zustands überhängen auswertet?

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

gandy

Zitat von: justme1968 am 05 April 2016, 13:21:03
das klingt auch interessant. für meine spülmaschine reicht ein watchdog.
Klar, dringend notwendig um das Programmende zu erkennen ist eine FSM nicht, aber es war ein überschaubarer  usecase für den Einstieg und nun ist es da...  ;D

Die Frage nach mehr Zuständen habe ich mir auch gestellt, letztenendes habe ich vorgezogen, die Bedingungen komplexer formulieren zu können um mit den vielen Zuständen den Überblick nicht  zu verlieren, gerade wenn Sequenzen ähnlich starten. Je komplexer die FSM wird desto wichtiger ist natürlich die Frage wie leicht man sie abändern/warten kann. Mein Ansatz mit Konfigdatei war da eher nicht so elegant gelöst.

Ein grafischer Editor wäre natürlich Luxus, soweit wollte ich bisher gar nicht träumen  :)

Was bei Auswerten von kurzen Sequenzen noch relativ unwichtig ist, mag bei länger dauernden Prozessen interessanter werden: Die Frage, wie teste ich die Statemachine? Ein Mechanismus zur Simulation mit Testdaten ist m.E. gerade beim Parametrieren auf dreistündige Waschprogramme sehr sinnvoll, v.a. wenn man bei einem Fehler nicht sofort eine neue Ladung anwerfen kann (wird beim Bierbrauen etc ganz ähnlich sein).

Zitat von: justme1968 am 05 April 2016, 13:21:03
meinst du es ist sinnvoll die statisik ins stateMachine modul einzubauen oder über ein allgemeineres modul wie statistics oder energyMonitor das nur die events zu den zustands überhängen auswertet?
Das war zu Beginn mein Ansatz, von dem ich dann aber abwich, weil ich die Readings ab dem Zeitpunkt auswerten wollte, ab dem das abgebildete Gerät seinen Zustand ändert. Im einen usecase eher Erbsenzählerei, in einem anderen vielleicht durchaus sinnvoll. Mit der richtigen Kombination aus Events und Aufwand lässt sich das vermutlich auch über bestehende Module abbilden.

Beste Grüße,
Andy.
fhem (svn) auf i5-4210U NUC
2x HMLAN, 19x HM-SEC-RHS, 15x HM-LC-Bl1PBU-FM, etc.
ODYS Neron Tablet / Android 4.2
Samsung Galaxy Tab 2 10.1N / Android 4.1.2
Samsung Galaxy Note / Android 6.0.1

frank

Zitatwer hätte interesse an einem solchen modul? welche features wären noch sinnvoll?
hört sich auf alle fälle interessant an.

im augenblick scheint es gänzlich eventgesteuert zu sein, ähnlich wie bei homematic.
da fehlt mir oft ein zustandsgesteuerter freigabeeingang mit definierten ausgangszuständen, um zb tagsüber grundsätzlich auszuschalten. das müsste natürlich auch einen reboot überleben.
oder auch eine zeitbasierte freigabe.

mit 2 statemachines könnte man dann auch 2 unterrschiedliche abläufe entsprechend toggeln.

gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Brockmann

Soweit ich das bislang verstehe, könnte man das ganze auch verwenden, um komplexere Abläufe zu erkennen und darauf zu reagieren. Das wäre für mich interessant. Beispielsweise abends automatisch in den Schlafmodus wechseln:
TV nach 20:00 Uhr an -> TV aus -> Licht im Bad an -> Licht im Bad wieder aus -> Licht im Schlafzimmer an -> Bewegungsmelder im Flur x Minuten ohne Bewegung =: Schlafmodus!

Wenn etwas in der Art damit realisieren kann, fände ich es sehr interessant.

Thyraz

Auf alle Fälle interessiert.

Ich habe einige solche Dinge bisher über DOIFs und einen Variablen-Dummy erledigt, bei dem ich Readings entsprechend auf 0 oder 1 oder sonstige Werte setzte.

Für Waschmaschine, Trockner etc. gibts da schon auch Anwendungsfälle.
z.B. Fehlermodus der Waschmaschine erkennen und Pushbenachrichtigung mit "Wasser aufdrehen vergessen", oder den Schleudergang am Ende der Wäsche erkennen.
Der Trockner verhält sich in der Abkühlphase auch anders gegen Schluss usw.

Aber gerade auch dimmbare Lampen die über Bewegungsmelder und Taster (plus Dimmen über Longpresses) gesteuert werden können bieten sich für sowas an.
Ich denke da gibt es genug Einsatzzwecke die sich damit einfacher und zentraler verwalten lassen würden.
Fhem und MariaDB auf NUC6i5SYH in Proxmox Container (Ubuntu)
Zwave, Conbee II, Hue, Harmony, Solo4k, LaMetric, Echo, Sonos, Roborock S5, Nuki, Prusa Mini, Doorbird, ...

Damian

Zitat von: Thyraz am 07 April 2016, 12:24:06
Auf alle Fälle interessiert.

Ich habe einige solche Dinge bisher über DOIFs und einen Variablen-Dummy erledigt, bei dem ich Readings entsprechend auf 0 oder 1 oder sonstige Werte setzte.

Für Waschmaschine, Trockner etc. gibts da schon auch Anwendungsfälle.
z.B. Fehlermodus der Waschmaschine erkennen und Pushbenachrichtigung mit "Wasser aufdrehen vergessen", oder den Schleudergang am Ende der Wäsche erkennen.
Der Trockner verhält sich in der Abkühlphase auch anders gegen Schluss usw.

Aber gerade auch dimmbare Lampen die über Bewegungsmelder und Taster (plus Dimmen über Longpresses) gesteuert werden können bieten sich für sowas an.
Ich denke da gibt es genug Einsatzzwecke die sich damit einfacher und zentraler verwalten lassen würden.

FSM lässt sich mit der nächsten Version von DOIF einfacher realisieren, siehe: https://forum.fhem.de/index.php/topic,51060.msg436110.html#msg436110

Aber eine schöne tabellarisch dargestellte FSM ist sicherlich kein schlechter Ansatz. 

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Doggiebert

Hurra!  :)

Mein Anwendungsfall, den ich jetzt mühsam mit dummy, readings, presence und notifies abbilde (und irgendwann den Überblick verliere...):

Rauf- und runterfahren eines PCs, d.h. Einschalten per WOL, Ausschalten per Eventghost. Ich will da natürlich nicht nur wissen, ob er gerade an oder aus ist, sondern ob er gerade beim Hoch- oder Runterfahren ist.
Das Ganze noch etwas komplexer mit einem Raspi, der hinter einer Funksteckdose hängt und der nur als XBMC-Device fungiert; wenn er oben ist, natürlich den Receiver einschalten und wenn er unten ist, die Steckdose wieder abschalten, etc.

Für die Statusübergänge bräuchte man m.E. Folgendes:

  • Übergang, wenn ein Event kommt (der Klassiker)
  • Übergang nach einer bestimmten Zeit (d.h. ich weiß, dass kein Event kommt - beispielsweise beim Runterfahren oder für Latenzen / Sicherheitspuffer
  • Beides (im Sinne eines Watchdogs, d.h. wenn ein eigentlich erwartetes Event ausbleibt)
...und idealerweise würde man auch jeweils anders reagieren (andere Aktionen, anderer Folgestatus), wenn der timeout kommt.

D.h. in der Logik den timeout eher gleichberechtigt zu den Events, mal ungefähr so:
{
OFF => [ { event => 'knopfgedrückt', action => '', newState => 'BOOTING'  }, ], \
BOOTING  => [
{ event => 'rechner meldet sich',   action => 'irgendwas',             newState => 'ON' },    \
{ event => 'knopfnochmalgedrückt',  action => 'runterfahren',          newState => 'SHUTDOWN'  }, ], \
{ timeout => 3s,                    action => 'mich benachrichtigen',  newState => 'FEHLER'  },    \
}

War das jetzt verständlich?

P.S.: <unverschämtmodus on> und dann natürlich im FHEMWEB eine Visualisierung als Petrinetz  8) <unverschämtmodus off>
SW: FHEM 5.5, Raspian, XBMC, Testinstallation auf Win7
HW: Raspi B, 32GB SD, enocean Pi, RFXTRX433E, BSC - MwC-32, Onkyo TX-NR709, Samsung UE55F8090, Jung LS-Eno, permundo SmartPlug, KDG-FB 6490cable (ohne FHEM)

justme1968

@frank: das abschalten lässt sich mit disable machen. das manuelle schalten lässt sich mit 'set state...' machen. auch das toggeln zwischen zwei unabhängigen abläufen. z.b. in dem man eine einzige state machine anlegt bei der die zustände nicht alle zusammen hängen sondern zwei oder mehrere getrennte graphen bilden. mit dem setzen des aktuellen zustandes lässt sich dann von einem zum anderen grafen springen.

@Brockmann: ja. das sollte gehen. vermutlich sogar recht übersichtlich und einfach zu debuggen in dem man für alle zwischenschritte jeweils einen zustand vergibt.

@Thyraz: genau. gerade taster sind sehr gut geeignet. es lassen sich zu allen kombinationen von short und long und release sehr einfach kommandos zuordnen. vor allem auch dinge wie das ein gerät bei jedem event eingeschaltet wird wenn es gerade aus ist, wenn es aber schon läuft die taster unterschiedliche aktionen triggern. die beispiele ganz oben machen genau das mit volume statt helligkeit.

@daminan: ja. besonders wenn man noch ein grafisches frontend dafür baut ist die tabelarische version einfacher zu parsen denke ich. 

@Doggiebert: alle drei varianten sollte mit dem unten beschriebenen möglich sein.

ansonsten gibt es im ersten post ein kleines update mit vier neuen features.

- zusätzlich zu action gibt es jetzt auch onEnter und onExit. diese werden beim ersten betreten und beim verlassen eines zustandes ausgeführt. action wird wie bisher bei jedem betreten des zustandes ausgeführt auch wenn der Übergang auf sich selbst ist.

- wenn man event leer lässt und timeout setzt greift die zeile nach dem timeout. auch ohne event. also z.b. x minuten aufheizen und dann weiter

- und es gibt ein retrigger schlüsselwort mit dem der gerade betretene zustand automatisch immer wieder getriggert wird. zu beispiel um automatisch rauf und runter zu dimmen oder lauter und leiser zu machen so lange eine taste gehalten wird.

retrigger liesse sich zwar auch mit 2. erledigen so spart es aber einen zustand.

- es gibt ein condition schlüsselwort. wenn eine condition gesetzt ist greift ein event nur wenn condition zu true auswertet

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Doggiebert

hab das gestern mal ausprobiert - den normalen Statusübergang kriege ich wunderbar hin, nur das mit dem Timeout und dem leeren Event habe ich mit den vorhandenen grauen Hirnzellen und auch mit einigem rumprobieren nicht hinbekommen...ich glaub' da bräucht' ich mal ein Beispiel...
Ansonsten: cool - ich glaub das Ding kann ich in meinem Setup ziemlich flächendeckend einsetzen und spar mir einige Dummy / notify / at - Klimmzüge...  8)
SW: FHEM 5.5, Raspian, XBMC, Testinstallation auf Win7
HW: Raspi B, 32GB SD, enocean Pi, RFXTRX433E, BSC - MwC-32, Onkyo TX-NR709, Samsung UE55F8090, Jung LS-Eno, permundo SmartPlug, KDG-FB 6490cable (ohne FHEM)

2P4u

Hi Andre.
Das wäre evtl. was für meine FHEM Cocktail Maschine https://forum.fhem.de/index.php/topic,55966.msg475386.html#msg475386

Also wenn du da dran bleibst wäre cool.
Es gibt schon viele Versionen der Cocktail Maschinen, aber ich fände es cool das mit FHEM zu Steuern.

Grüsse Daniel
1x Ubuntu Server
1x LaCrosse Gateway für PCA301 /1x HMLAN /1x HMLGW
2x HueBridge mit Devices/ 1x Logitech Harmony Ultimate

justme1968

ja. das modul wird noch weiter entwickelt (auch wenn es nicht so ausschaut :) ).

so eine maschine klingt interessant. automatisch eis wäre glaube ich noch wichtig :)

ob stateMachine passt oder ob es auch einfacher/anders geht kann ich dir aber nicht sagen.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968