HM-PB-6-WM55 <-FHEM-> HM-LC-Sw4-DR: "Echte" Rückmeldung an Taster?

[frank]

commandref/notify => $EVTPART

2 klammern weniger

Code Auswählen Erweitern

define di_1 notify EG_FL_6CH_CH1 {\
fhem ( "set KG_ZS_4CH_CH1 on" );; \
if ( $EVTPART1 =~ m/(\d+)0_/ ) { fhem ( "set KG_ZS_4CH_CH1 off" );; fhem ( "set KG_ZS_4CH_CH1 on" ) }
}

[M_I_B]

... huppsi ... Jetzt wo Du's erwähnst Bei so viel Klammerei kann man schon mal den Überblick verlieren und sieht's dann auch beim 100ten mal drüberlesen nicht...

aBär.. an der Ablaufgeschwindigkeit hat sich nichts getan. Wenn ich mir den Counter anschaue, reagiert der Aktor im besten Fall das erste mal auf den Null- Durchlauf, wenn der Counter schon bei 17 steht, oft aber erst, wenn der Counter 30 deutlich überschritten hat.
Wenn man sich so den Counter auf der GUI anschaut fällt auf, das er recht langsam läuft bis zu dem Zeitpunkt, wo man die Taste wieder löst. Dann hat er es für ein paar weitere Zählschritte sehr eilig. Das verleitet mich zu der Vermutung, das der RPi/FHEM so sehr damit beschäftigt ist, die Datenpakete entgegen zu nehmen, das er zu nix anderem mehr kommt. Also habe ich mal X gestartet und mir die Prozessorlast angesehen... Fehlanzeige. In Ruhe liegt die Last so bei 0-1%, Bei Festhalten der Taste maximal 7%. Finde ich zwar schon viel, aber ist weit entfernt von kritischen Lastwerten. Vermutung also selbst wiederlegt.
Die Frage ist nur, woran es denn sonst liegen könnte?!?

[M_I_B]

... ich habe es jetzt mal anders versucht. Zumindest stottert der Counter jetzt nicht mehr, aber funktionieren tut's leider auch nicht.. Ich arbeite noch dran:

Code Auswählen Erweitern

altlast entsorgt

... an dieser Stelle gebe ich erstmal (für heute) auf
Kurzer Tastendruck wird korrekt als toggle umgesetzt, aber so bald ich einen langen Tastendruck erzeuge, läuft FHEM in eine Endlosschleife, die sich auch nicht durch stoppen und starten des FHEM- Dienstes stoppen lässt. Nur der Neustart des RPi hilft.
Ich komme einfach nicht dahinter, wo mein Denkfehler ist...

Code Auswählen Erweitern

define di_1 notify EG_FL_6CH_CH1 { \
if ( $EVENT =~ /\Short/m ) { \
fhem ( "set KG_ZS_4CH_CH1 toggle" );; \
} elsif ( $EVENT =~ /\Long./m ) { \
fhem ( "set KG_ZS_4CH_CH1 on" );; \
my $timer = 3;; \
while ( $EVENT =~ /\Long./m ) { \
if ( $EVTPART1 =~ /(\d+)0_/m ) { \
$timer = $timer ** $1;; \
fhem ( "set KG_ZS_4CH_CH1 off;; set KG_ZS_4CH_CH1 on" );; \
} \
} \
fhem ( "set KG_ZS_4CH_CH1 on-for-timer ". $timer );; \
} \
}


[frank]

das while würde ich mal dringend entsorgen.
$EVENT ändert sich nicht, daher gibt es keinen ausgang.

[M_I_B]

... Echt? Wieso ändert sich $EVENT nicht? Nach allem was ich gelesen und verstanden habe, steht doch in $EVENT genau das drin, was die Taste gerade sendet, also entweder "Short", "Long x1_x2", oder "LongRelease x1_x2"?!?
Aber auch mal angenommen, es ändert sich nicht, dann kann WHILE nur mit Long aufgerufen werden. Bei Short wird das While übersprungen, und nur Long wird in der ELSIF akzeptiert. Also müsste zumindest der Befehl ON nach ELSIF noch ausgeführt werden. Aber bis dahin komme ich gar nicht, also nach meinem Verständnis auch nicht zum WHILE. Aber auch wenn, dann müsste das WHILE zumindest dauerhaft laufen. Aber das FHEM schmiert wie gesagt irgendwo komplett ab und ist nur durch einen kompletten ReBoot zu reaktivieren...

Du verwirrst mich

[justme1968]

fhem ist nicht multithreaded und arbeitet event basiert. so lange du in dein er while schleife bist macht fhem nichts anderes als deine while schleife abzuarbeiten. jede art von schleife um auf änderungen zu warten ist konzeptionell falsch und funktioniert nicht.

wenn du je nach zustand unterschiedlich auf events regieren willst ist es am besten alles in 99_myUtils auszulagern und eine state machine zu verwenden.

gruss
  andre

[frank]

steht doch in $EVENT genau das drin, was die Taste gerade sendet,

fhem grundkurs: 0. vorwort

in fhem gibt es im prinzip keine parallelverarbeitung.
events werden nacheinander erzeugt (siehe eventmonitor) und nacheinander abgearbeitet und dienen der kommunikation zwischen verschiedenen modulen. ein notify zb lauscht permanent auf passende events.
wenn nun das aktuell zu verarbeitende event auf die regex deines notifys passt, werden die daten des events an dein notify übergeben und es wird abgearbeitet. während der laufzeit deines notifys ändern sich die eventdaten nicht.

andre war schneller.

[M_I_B]

... ok, jetzt leuchtet mir das auch ein und erklärt das von mir unerwartete Verhalten.. Schidde... Holzweg 

alles in 99_myUtils auszulagern und eine state machine zu verwenden.

Noch nie von gehört/gelesen (von der state machine meine ich). Gibt es da irghendwo was schlaues drüber zu lesen, wie man so was anstellt?

[martinp876]

hm ... wie wärs mit wiki?
http://www.fhemwiki.de/wiki/HM-Dis-WM55_Funk_Statusanzeige

[M_I_B]

... nett, auch wenn ich ...

... kein Wort von dem dort gesagten verstehe ...
... ich kein HM-Dis-WM55 habe ...
... ich dort an keiner Stelle die Bezeichnung "event machine" finden konnte ...
... und somit auch die Suche danach nicht auf dieses Dokument verwiesen hat.

Daher im Moment: Nicht hilfreich.

[justme1968]

eine finite state machine bzw. endlicher automat ist ein konstrukt mit dem das verhalten eines systems durch eine menge von zuständen und die übergänge zwischen diesen beschrieben wird.

bei wikipedia gibt es mehr oder weniger theoretische beschreibungen, der von martin verlinkte artikel beruht auch auf einer state machine.

das schaut im ersten augenblick zwar kompliziert aus ist aber wenn das prinzip klar ist sehr viel einfacher zu warten und zu erweitern.

der knackpunkt ist das nicht mehr ein unüberschaubarer wust von verschachtelten if/else konstrukten verwendet werden sondern die zustände durch datenstrukturen beschrieben werden und es im prinzip nur noch eine einzige routine gibt die gesteuert durch den aktuellen zustand und den aktuellen input in den neuen zustand wechselt und dabei als 'seiteneffekt' die gewünschten aktionen auslöst.

diese routine kann sehr generisch implementiert und so für alle möglichen aufgaben wiederverwendet werden. nur die beschreibung der zustände und aktionen wäre jeweils individuell.

ein solches modell passt sehr gut zum event gesteuerten modell das fhem vorgibt.

such ein bisschen bei google. lese dich langsam ein. nicht durch die seiten mit theoretischen anstrich abschrecken lassen. es ist wirklich eine praktische sache. ein schöner aspekt ist das man gezwungen wird sich über die zustände und übergänge gedanken zu machen und diese auch gut aufmalen kann.

gruss
  andre

ps: wenn ich so drüber nachdenke wäre das eigentlich fast ein fhem modul wert. zustände und aktionen definieren und die events die dann die übergänge herbeiführen...

[M_I_B]

... damit kann ich was anfangen! Vielen Dank für die ausführliche Erklärung. Das bringt mich deutlich weiter, als ein Link ohne weitere Erklärungen

ps: wenn ich so drüber nachdenke wäre das eigentlich fast ein fhem modul wert. zustände und aktionen definieren und die events die dann die übergänge herbeiführen...

... ich bin dafür! 

[martinp876]

hm - dieser Teil ist frei programmierbar. das wird etwas schwer, ohne Flexibilitaet einzubüsen. Möglich ist alles, ob es einfacher wird - hängt vom Standpunkt ab.
Das Beispiel in Wiki ist voll funktionsfähig - ist doch eigentlich ein Modul.

[M_I_B]

... ok ... Da mir die Nummer mit der "event machine" im Moment noch eine Nummer zu fett ist, habe ich nach einer anderen Lösung gesucht und wohl auch theoretisch gefunden; wenn sie denn funktionieren würde:

Code Auswählen Erweitern

define di_1 notify EG_FL_6CH_CH1 { \
if ( $EVENT =~ /\Long.*/m && $multi == 0 ) { \
my $timer = 3;; \
my $multi = 1;; \
fhem ( "set KG_ZS_4CH_CH1 on" );; \
} elsif ( $EVENT =~ /\Long.*/m && $multi != 0 ) { \
$timer = 0;; \
$multi = 0;; \
fhem ( "set KG_ZS_4CH_CH1 off" );; \
} elsif ( $EVENT =~ /\Short.*/m && $multi != 0) { \
fhem ( "set KG_ZS_4CH_CH1 on-for-timer ". $timer ** $multi );; \
} \
}

Das ist eine der versuchten Varianten, die nicht funktioniert, weder auf Short noch auf Long. Ich vermute, das ich mangels Erfahrung mit perl da irgend etwas übersehe. Was ich auch nicht rausbekommen konnte ist, ob hier perl im strict- Modus arbeitet und ich zwingend die Variablen vorher deklarieren muss? Wenn ja, sollte das nach meinem Verständnis an einer Stelle geschehen, die beim Starten von FHEM einmal durchlaufen wird, da ja ansonsten die Variablen immer neu deklariert werden; nur wo? Oder macht das nix?

[justme1968]

ich bastle gerade an einem state machine modul, mal sehen ob das was wird...

zu deinem problem: du musst variablen deklarieren und wenn du sie über einen scope (notify aufruf) hinüber retten willst gibt es zwei möglichkeiten: in ein reading stecken und wieder auslesen, den ganzen code in 99_myUtil stecken und die variablen dort ausserhalb der sub deklarieren.

eventuell hilft dir auch OldValue um auf den vorherigen STATE wert zuzugreifen.

gruss
  andre