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

amithlon

Hallo,

die oben angesprochene Zustandserkennung bei E3000 Messgeräten kenne ich irgendwie. Bei meiner Billg-Kaffemaschine gibt es zum Glück nur 0W oder rund 800W...
Der Ansatz, über den Momentanverbrauch den Zusand zu erfassen, ist aber interessant.

Zitat von: Doggiebert am 07 April 2016, 13:28:18

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.


Hier werkelt ein RasPi als Streamplayer für einen internen Icecast-Stream. Warum? RasPi lag rum und USB-Soundkarte auch...
Hängt auch an einer Funksteckdose zusammen mit dem aktiven Subwoofer, hat sich so ergeben.

Einschalten über IR-Fernbedienung beim Starten des alten Sony-Receivers über "Video-In", da hängt der RasPi Sound dran. Weiter parallel zu FHEM (IR-Receiver), Raspi wird per LAN-Ping überwacht und wenn er da ist. Dann wird aus dem roten LED im Statusbild in FHEM ein Ausschaltbutton.
Der fährt den RasPi per telnet runter und schaltet 30s später die Funksteckdose aus.

Ließ sich eigentlich ganz gut in FHEM realisieren wenn man von meiner "Diskussion" absieht, den shutdown now zum RasPi zu bekommen...

Ich müßte meine Konstrukte vermutlich mal aus Sicht stateMachine betrachten.

PS: ich hatte vor Jahrzehnten mit einer Honywell Delta 1000 zu tun, Gebäudeautomatisation.
Das war alles Event-basiert und man mußte manchmal seltsame Wege gehen für eine bestimmte Funktion.
Trotzdem finde ich jetzt vieles vom Konzept in FHEM wieder, was mir das Verständnis leichter macht.

Gruß aus Berlin
Michael

akw

Hallo justme,

ist die Entwicklung an dem Modul noch aktiv?

Ich benötige eine Sequenzerkennung. (Siehe https://forum.fhem.de/index.php/topic,60088.0.html )

Ich möchte ein paar Knöpfe in einer bestimmten Sequenz innerhalb einer bestimmten Zeit drücken und dann soll was passieren.

Ciao, Arno
FHEM-SVN auf MacMini OSX 10.7.5

FS20,FHT,HMS,CUL_WS,CUL_HM,KS300,HUE,FB_DECT

FHEMobile: www.fhemobile.de

justme1968

hallo arno,

das modul soll noch weiter entwickelt und dann auch eingecheckt werden.

aber schau dir für deine anwenung sequence noch mal an. das macht schon genau das was du möchtest.

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

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

knopf_piano

anlehnung an uml?
timer, event, transition, entry, exit, condition, laufvariablen
wish-list: state-anzeige, welches event schlägt zu, event als enumwert, , debugging, simulation der SM

idee, das attr in eine cfg-txt/xml-table zu schieben? die könnte dann aus nem egal-was-tool oder pl-script generiert werden

viele, viele ideen...
zotac nano mit proxmox und ganz viel zeug drauf

Prof. Dr. Peter Henning

Wenn jemand hier nach Mitternacht Ideen einträgt, kommt mir manchmal das Wort "Geisterstunde" in den Sinn...

Die Beschreibung eines komplexem Systems wie einer State Machine ist auch mit UML noch eine schwarze Kunst. Ein anderer erfolgversprechender Ansatz wird hier geboten:
https://sourceforge.net/projects/smdl/

Der langen Rede kurzer Sinn: Für ganz einfache Automaten kann das so umgesetzt werden, wie Andre es vorhat. Der gegenwärtige Stand der Forschung lässt mich aber stark daran zweifeln, dass komplexere oder allgemeinere Automaten mit einem FHEM-Modul gebaut werden können.

LG

pah

rudolfkoenig

ZitatDer gegenwärtige Stand der Forschung lässt mich aber stark daran zweifeln, dass komplexere oder allgemeinere Automaten mit einem FHEM-Modul gebaut werden können.

Dieser Satz kann leicht von Leuten ohne tiefere Kenntnisse falsch interpretiert werden deswegen eine kleine Ergaenzung: Mit FHEM bzw Perl koennen beliebig komplexe Automaten gebaut werden, ich meine hier wird nur bezweifelt, ob das mit in einer tabellenartigen Struktur / XML-Dokument (im Gegensatz zu einer klassischen Programmiersprache) geht. Meine Erfahrung ist: das geht, ist aber je nach Problemstellung deutlich aufwendiger zu bauen oder zu pflegen, als es mit klassischen Programmiersprachen der Fall ist, und damit waeren wir bei schwarzer Kunst.

justme1968

oder noch anders ausgedrückt:

wenn das projekt so komplex wird das die beschreibung in einer state machine ohne weitere hilfsmittel nicht mehr genügt und die hilfsmittel selber in komplexität und implementierungsaufwand in richtung einer kompletten programmiersprache gehen, dann kann man auch gleiche eine solche verwenden. zumal wir mit fhem die perfekte integration einer solchen schon haben :).
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

knopf_piano

#22
Zitat von: Prof. Dr. Peter Henning am 06 November 2016, 08:29:06
Wenn jemand hier nach Mitternacht Ideen einträgt, kommt mir manchmal das Wort "Geisterstunde" in den Sinn...
der jemand sagt: "Danke für die Blumen".
Schade, dass Denkanstöße oder Ideen deinerseits pauschal mit dieser Wortwahl kommentiert werden.
Wenn eine SW-Entwicklung und Ideen dazu in der freien Wirtschaft identisch attributiert werden, sieht's in Zukunft schlecht aus...
zotac nano mit proxmox und ganz viel zeug drauf

Prof. Dr. Peter Henning

@Rudi: Fast voll Zustimmung. Mit Perl: Ja. Mit FHEM: Da habe ich so meine Zweifel, ob beliebig komplexe Automaten gebaut werden können. Die Komplexität ist übrigens der Grund dafür, dass die verlinkte SDML nicht so richtig weiter verfolgt wird.

@knopf_piano: Nach Mitternacht kommen auch in der "freien Wirtschaft" meist keine guten Ideen mehr. Und abgewürgt habe ich auch nichts: Es steht jedem frei, mich durch die Realisierung eines von mir als eher aussichtslos eingestuften Projektes zu widerlegen. Allerdings sollte derjenige das dann auch selbst machen, und nicht einfach wilde Ideen äußern, die andere dann btte programmieren sollen.

LG

pah

knopf_piano

@pah:
Ich habe nichts gegen eine persönliche und sachliche Einschätzung einer Machbarkeit, im Gegenteil.
Der süffisante Unterton "Geisterstunde" wirkt für mich jedoch nicht sehr respektvoll.
zotac nano mit proxmox und ganz viel zeug drauf

Prof. Dr. Peter Henning

Hm, da stehen wir wohl auf verschiedenen Seiten. Denn ich finde es nicht sonderlich respektvoll, einfach einen Wust von Wünschen und Ideen hier auszukippen.

LG

pah

uniqueck

Hi André,

ich hatte gestern auch die Idee eine StateMachine als Modul zu entwickeln und dachte du schaust lieber mal noch im Forum danach, ob nicht jemand schon solch eine Idee hatte.
Und siehe da, du hast dir schon die Mühe gemacht.

Ich würde es noch als sinnvoll erachten, die erkannten States als Reading bereitzustellen, da ich gestern beim Anlegen ein oder zwei Fehler gemacht hatte, welche zwar syntaktisch keine Auswirkung hatten, aber dazu geführt hatten, dass die möglichen states nicht erkannt wurde.

Ich kann das auch gerne übernehmen, des Weiteren wollte ich noch anmerken, dass ich es für mich erstmal in ein git Repository gepackt habe, damit ich bei Anpassungen es nicht immer manuell hin und her kopieren muss.
Es soll allerdings nicht der Eindruck entstehen, dass es von mir ist, ich würde es nur solange da halten, sobald es entweder von dir in einem bereitgestellt wird, oder aber natürlich in FHEM Standard mit übergeht.

Für die gemeinsame Entwicklung finde ich es allerdings in einem Repository geschickter, als es hier immer an einen entsprechenden Post zu hängen.

Hättest du da etwas dagegen?

Link zu Repository: https://github.com/uniqueck/fhem-statemachine

gruß constantin

justme1968

nur zu. tob dich aus. ich komme gerade nicht dazu.

wenn das modul in einem verwendbaren zustand ist soll es auf jeden fall ganz normal eingecheckt werden.

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

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

uniqueck

Zitat von: gandy am 05 April 2016, 13:00:35
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.

Möchtest du dein Modul hier teilen, dann kann ich ja mal schauen, was davon alles in das stateMachine Modul übernommen werden kann, oder du hilfst selber mit.

Ich denke das wichtigste sind dann erstmal Bedingungen, bei den events.

Gruß Constantin

gandy

Hi Constantin,

den Code teile ich gerne, allerdings habe ich daran seit längerem nichts mehr gemacht, außer auf Probleme bei FHEM-Updates oder neuen Perl-Versionen zu reagieren. Die Konfiguration einer Statemachine funktioniert beim beigefügten Modul über eine Konfigdatei, davon habe ich ein paar beigefügt. Das würde ich inzwischen nicht mehr so lösen, weil es beim Aufsetzen und Optimieren einer neuen Statemachine zu sperrig ist.

Leider habe ich im Moment nicht wirklich die Zeit, mich intensiv mit einzubringen, konkrekte Fragen zum Code beantworte ich aber gerne.

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

pst

Habe dieses Modul entdeckt und finde die Idee dahinter super.
Nun wollte ich es an einem einfachen Beispiel testen... klappt aber nicht.
Was ich habe:

Internals:
   DEF        Switch_Sonnenaufgang,Switch_Sonnenuntergang,Switch_Tag,Switch_Nacht hueBridge1_.*
   NAME       MODUS
   NR         315
   NTFY_ORDER 50-MODUS
   STATE      OFF
   TARGET     hueBridge1_.*
   TYPE       stateMachine
   Content:
     Switch_Nacht 1
     Switch_Sonnenaufgang 1
     Switch_Sonnenuntergang 1
     Switch_Tag 1
   DEVICES:
     Switch_Sonnenaufgang
     Switch_Sonnenuntergang
     Switch_Tag
     Switch_Nacht
   Helper:
     Transitions:
       ABEND:
         HASH(0x27889f8)
       MORGEN:
         HASH(0x2788920)
       NACHT:
         HASH(0x2788b78)
       TAG:
         HASH(0x2788ab8)
Attributes:
   start      MORGEN
   stateFn    MORGEN
   transitions {
MORGEN => [ { event => '$3:on', action => 'set $TARGET off',    newState => 'TAG'     },],
ABEND  => [ { event => '$4:on', action => 'set $TARGET off',    newState => 'NACHT'   },],
TAG    => [ { event => '$2:on', action => 'set $TARGET on',     newState => 'ABEND'   },],
NACHT  => [ { event => '$1:on', action => 'set $TARGET on',     newState => 'MORGEN'  },],
}

Die 'Switch_xxxx'es sind dummys. Ich möchte über events (hier das schalten eines dummys) den state of the day ändern.
Als Action habe ich gerade nur das an/aus machen von Lampen. Hier würde ich dann noch Funktionen rufen wollen.
Leider reagiert hier nix. Im log finde ich:
2017.03.28 09:54:04 2: MODUS: unhandled state: OFF
2017.03.28 09:58:37 2: MODUS: unhandled state: Unknown command MORGEN, try help.

Nun meine Fragen:
- braucht es den state ON/OFF zwingend in den transitions (in den bsps. ist das so).
- kann man in action auch Functions rufen
- wie greife ich auf den state zu innerhalb von Functions (wahrscheinlich mit readingsVal())
- in meinem Fall würde die stateMachine ja nie enden... geht das?
- ist das event richtig def. (bei dummy $1 (mit on/off) mit '$1:on'... oder ist das 0/1)

Über eine Antwort würde ich mich sehr freuen.
Viele Grüsse aus dem Schwarzwald.
Stephan

Prof. Dr. Peter Henning

Ernst gemeinter Tipp: Erst einmal etwas mehr mit den Grundlagen von FHEM vertraut machen.

LG

pah

chefpro

Hallo,

Sorry, dass ich den alten Thread wieder raus hole. Es gibt aber Neuigkeiten.

Ich habe mal ein PR für das Repo gemacht.
Wenn das dann gemerged ist sollten "timed transitions" funktionieren.

Das heißt es funktioniert dann eine transition anzulegen die nur einen Timeout hat aber kein Event.

Wenn im angegebenen Zeitraum dann keine andere Transition triggert, wird der Status gewechselt.

Beispiel: "{ timeout => 10, action => 'set something OFF', newState => 'OFF' },"

Grüße, Peter