Funktaster von HM geben mehr als ein Event zurück

Begonnen von Grünling, 11 Januar 2015, 21:45:05

Vorheriges Thema - Nächstes Thema

Grünling

Hallo,

ich bin neu und habe mich von einem Kollegen, der mir schon viel geholfen hat, zum FHEM mit Homematic_Komponenten inspirieren lassen. Die Steuerung der Heizung mit Therme und der Abfrage, ob wir zu Hause sind funktioniert schon gut und fehlerfrei. Jetzt sollte die Beleuchtung dran sein. Das gewünschte Verhalten sollte sein, das mit LongRelease das Licht in Abhängigkeit der Tageszeit zu einem bestimmten Dimm-Wert an gehen soll und beim nächsten LongRelease wieder aus gehen soll. Das Verhalten lässt sich mit einem Notify und einer verschütteten IF-Abfrage gut erreichen. Das Problem ist, das das LongRelease-Event beim los lassen offensichtlich nicht nur ein sondern 2 Events sendet. Das heißt das Licht geht an und sofort wieder aus. Bei einer Abfrage auf Short schien es zu funktionieren. Bei unserem Test stellten wir aber fest, das es bei Short 3 Events sendet und dadurch funktioniert, das es ein-aus-ein Schaltet. Im Moment kann ich also keine LongRelease abfragen.

Hier das Notify zum abfragen der Schaltungen:
define TestNot notify fl_LS.*.LongR.* {fhem('setreading Test counter '.(ReadingsVal('Test', 'counter', 0)+1))}

Das Ergebnis im Eventlog sieht dann so aus (Interessant ist das counter auf 41 und dann gleich auf 42 gehoben werden):
Events:
2015-01-11 20:25:18 CUL_HM fl_LS1_Btn_02 trigger_cnt: 15
2015-01-11 20:25:18 CUL_HM fl_LS1_Btn_02 Long 1-8440- (to CUL868)
2015-01-11 20:25:18 CUL_HM fl_LS1_Btn_02 trigger: Long_15
2015-01-11 20:25:18 CUL_HM fl_LS_1 battery: ok
2015-01-11 20:25:18 CUL_HM fl_LS_1 fl_LS1_Btn_02 Long 1-8440- (to CUL868)
2015-01-11 20:25:18 CUL_HM fl_LS1_Btn_02 trigger_cnt: 15
2015-01-11 20:25:18 CUL_HM fl_LS1_Btn_02 Long 2-8440- (to CUL868)
2015-01-11 20:25:18 CUL_HM fl_LS1_Btn_02 trigger: Long_15
2015-01-11 20:25:18 CUL_HM fl_LS_1 battery: ok
2015-01-11 20:25:18 CUL_HM fl_LS_1 fl_LS1_Btn_02 Long 2-8440- (to CUL868)
2015-01-11 20:25:18 CUL_HM fl_LS1_Btn_02 trigger_cnt: 15
2015-01-11 20:25:18 CUL_HM fl_LS1_Btn_02 Long 3-8440- (to CUL868)
2015-01-11 20:25:18 CUL_HM fl_LS1_Btn_02 trigger: Long_15
2015-01-11 20:25:18 CUL_HM fl_LS_1 battery: ok
2015-01-11 20:25:18 CUL_HM fl_LS_1 fl_LS1_Btn_02 Long 3-8440- (to CUL868)
2015-01-11 20:25:19 dummy test2 counter: 41
2015-01-11 20:25:19 dummy test1 0
2015-01-11 20:25:19 dummy test 1
2015-01-11 20:25:19 Global global DEFINED test_AT
2015-01-11 20:25:19 CUL_HM fl_LS1_Btn_02 trigger_cnt: 15
2015-01-11 20:25:19 CUL_HM fl_LS1_Btn_02 trigDst_F11034: noConfig
2015-01-11 20:25:19 CUL_HM fl_LS1_Btn_02 LongRelease 4-A240- (to CUL868)
2015-01-11 20:25:19 CUL_HM fl_LS1_Btn_02 trigger: Long_15
2015-01-11 20:25:19 dummy test2 counter: 42
2015-01-11 20:25:19 dummy test1 0


Der Test auf Short brachte folgendes Ergebnis:
Events:
2015-01-11 20:38:01 dummy test2 counter: 63
2015-01-11 20:38:01 dummy test2 counter: 64
2015-01-11 20:38:01 dummy lichttest 45 120 0
2015-01-11 20:38:01 dummy lichttest 0
2015-01-11 20:38:01 CUL_HM fl_LS1_Btn_02 trigger_cnt: 21
2015-01-11 20:38:01 CUL_HM fl_LS1_Btn_02 trigDst_F11034: noConfig
2015-01-11 20:38:01 CUL_HM fl_LS1_Btn_02 Short (to CUL868)
2015-01-11 20:38:01 CUL_HM fl_LS1_Btn_02 trigger: Short_21
2015-01-11 20:38:01 dummy test2 counter: 65
2015-01-11 20:38:01 dummy lichttest 45 120 0
2015-01-11 20:38:01 CUL_HM fl_LS_1 battery: ok


Ist das Phänomen bekannt? Was kann ich dagegen tun?
Wenn noch was zur Analyse fehlt, bitte Bescheid sagen ich bin wie gesagt neu hier.

Hardware: Zentrale :http://forum.fhem.de/index.php/topic,29795.0.html
                Taster: HM-PB-2-WM55-2

Danke schon mal!

Grünling

Rince

Du könntest mal versuchen mit
event-min-interval 3
oder so in der Art 3 Sekunden lang nimmer auf das Event zu reagieren.


Das mehrere longEvents gesendet werden ist von HM so gewollt. Wenn du noch länger auf der Taste bleibst, gibt es sogar noch mehr davon ;)
Wer zu meinen Posts eine Frage schreibt und auf eine Antwort wartet, ist hiermit herzlich eingeladen mich per PN darauf aufmerksam zu machen. (Bitte mit Link zum betreffenden Thread)

DerFrickler

Zitat von: Rince am 11 Januar 2015, 22:13:07
Du könntest mal versuchen mit
event-min-interval 3
oder so in der Art 3 Sekunden lang nimmer auf das Event zu reagieren.


Das mehrere longEvents gesendet werden ist von HM so gewollt. Wenn du noch länger auf der Taste bleibst, gibt es sogar noch mehr davon ;)

Ich habe mit dem event-min-interval so meine Probleme.. z.B. dass es die Intervallzeit nicht einhält oder dass es ohne ersichtlichen Grund (es gab zwischenzeitlich keine Änderung) das Event dann exakt nach Ablauf des Intervalls ausgelöst wurde.

nur mal so als Beispiel:
2015-01-11 22:52:42 FBDECT FBDECT_20000 power: 23.67 W
2015-01-11 22:54:12 FBDECT FBDECT_20000 power: 23.74 W (hier wurde das Event 30 Sekunden zu früh ausgelöst)
2015-01-11 22:55:12 FBDECT FBDECT_20000 power: 23.60 W (hier sogar 60 Sekunden)

Möglicherweise hilft dir aber ein DOIF mit cmdpause wie hier beschrieben (http://forum.fhem.de/index.php/topic,31943.15.html) weiter.

stromer-12

Ich teste auf "trigger" und werte dann entspechend aus. Es kommt bei gesetzten event-on-change-reading nur ein trigger.

HM_PB_2_WM55_(..)_Btn_0[1-2]:trigger:.* {
  Log 4,"2fach-Taster %NAME %EVTPART1";
  if("%NAME" =~ m/02_Btn_02/){
    Log 4,"schalte Schreibtischlampe";
    if ("%EVTPART1"  =~ m/Short/){
      if (Value("FS20_095ec1") eq "off"){
        CommandSet(undef, "FS20_095ec1 on-for-timer 120");
      }else{
        CommandSet(undef, "FS20_095ec1 off");
      }
    }else{
      CommandSet(undef, "FS20_095ec1 on");
    }
  }
  if("%NAME" =~ m/0[13]_Btn_01/){
    Log 4,"schalte Badoberlicht";
    if ("%EVTPART1" =~ m/Short/){
      if (Value("FS20_095ec3") eq "off"){
        CommandSet(undef, "FS20_095ec3 on");
      }else{
        CommandSet(undef, "FS20_095ec3 off");
      }
    }else{
      CommandSet(undef, "FS20_095ec3 t3_00");
    }
  }
}
FHEM (SVN) auf RPi1B mit HMser | ESPLink
FHEM (SVN) virtuell mit HMLAN | HMUSB | CUL

frank

ZitatDas Problem ist, das das LongRelease-Event beim los lassen offensichtlich nicht nur ein sondern 2 Events sendet.
ich kann in deinem eventlog nur ein longrelease entdecken. entweder du verheimlichst noch events oder die regex deines notify macht ärger. den punkt vor dem ".LongR" würde ich schon mal löschen.
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

RoBra81

Hallo,

ich bin der Kollege :-)
Der Kollege hat Grünling hat sich etwas ungünstig ausgedrückt: der Event LongRelease wird nicht mehrfach ausgelöst, sondern ein notify, das auf diesen Event reagiert wird mehrfach ausgelöst obwohl der Event nur einmal kam. Auf dieses Phänomen sind wir gestoßen, indem wir ein notify definiert haben, das bei einem LongRelease-event das Reading counter des dummys test2 um 1 erhöht. Wie man im Log sieht, wird das Reading beim LongRelease jedoch um zwei erhöht (beim short sogar um 3). Das Problem ist, dass Grünling ein notify definieren wollte, dass bei Licht aus das Licht einschaltet und anderenfalls das Licht aus schaltet (bitte keine Diskussionen, dass man das anders machen kann - das ist nur ein Teil des notifys ;-)) -> das Problem ist nun, dass beim Short das eingeschaltete Licht aus, ein und wieder aus geschaltet wird (Zielzustand auf Umwegen erreicht), beim LongRelease-Event wird das eingeschaltete Licht jedoch aus und wieder eingeschaltet (Zielzustand nicht erreicht).

Hat jemand eine Idee dazu? Grünling kann bei Bedarf auch gern noch die lists des Dummys und des notifys posten...

Ronny

frank

wenn die geposteten events komplett sind, wird das notify sicherlich nur einmal ausgeführt, da der string "LongR" nur einmal enthalten ist.

probleme bereitet eventuell das setreading. ich habe auch ein seltsames verhalten mit setreading im notify gehabt. siehe hier http://forum.fhem.de/index.php/topic,26826.msg197803.html#msg197803. den grund habe ich aber immer noch nicht verstanden.  8)

ändere das notify mal in:

define TestNot notify fl_LS.*.LongR.* {Log 1,"------ test ----- $NAME $EVENT"}

und schaue ins fhem.log. bei jedem event gibt es ein logeintrag, der dir das device und das event zeigt.
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

Rince

Probier doch das min-interval mal aus...

Dann dürfte das Notify nur 1x triggern
Wer zu meinen Posts eine Frage schreibt und auf eine Antwort wartet, ist hiermit herzlich eingeladen mich per PN darauf aufmerksam zu machen. (Bitte mit Link zum betreffenden Thread)

Grünling

So, das Problem scheint ein anderes gewesen zu sein. Mein Logfile beinhaltete tausende von Fehlermeldungen á:
PERL WARNING: Possible precedence problem on bitwise | operator at (eval 238429) line 1.
Dadurch scheint irgend was durcheinander gekommen zu sein. Ich habe also alle "|" in "or" umgewandelt.
Jetzt wird der count aus dem Test
define TestNot notify fl_LS.*.LongR.* {fhem('setreading Test counter '.(ReadingsVal('Test', 'counter', 0)+1))}
nur noch um eins erhöht. Egal welche Abfrage ich mache.

Danke trotzdem für die Hilfe.

Das meine Notifys immer noch nicht machen, was ich möchte muss ich erst mal selber nachforschen. Das scheint jetzt andere Ursachen zu haben.

Grünling