Homematic Vierfach-Handsender schaltet doppelt bzw. mehrfach

[frank]

Code Auswählen Erweitern

2018.08.20 22:53:19 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D0CC9E d:FF r:FFB0     m:BA A640 652E9A 424242 051B
2018.08.20 22:53:19 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D0CE03 d:FF r:FFAF     m:BB A240 652E9A 424242 051B
2018.08.20 22:53:20 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D0CF67 d:FF r:FFB0     m:BC A240 652E9A 424242 051B

der taster sendet immer 3 messages an die zentrale mit der selben triggerinfo. die letzten 4 zeichen, wobei die letzten 2 zeichen die eventnummer ist.
warum das so ist, ist mir allerdings unklar.
ich vermute er sendet einmal an die gepairte zentrale und einmal an den peer. bei einem adressaten wird dann eventuel 1x wiederholt (peer?), da kein ack kommt.
acks kann man leider nicht sehen, da der hmusb solche acks von sich aus macht.

vielleicht würde das entpeeren helfen.

aber auch ohne entpeeren solltest du es hinbekommen, indem du auf das trigger reading reagierst und event-on-change nutzt.

[Otto123]

Zu Franks Idee:
Du hast sogar zwei Events auf die Du triggern kannst

Code Auswählen Erweitern

2018-08-25 12:06:36 CUL_HM HM_Switch_Btn_11 trigger: Short_94
2018-08-25 12:06:37 CUL_HM HM_652E9A HM_Switch_Btn_11 Short

dazu

Code Auswählen Erweitern

attr HM_Switch_Btn_11 event-on-change-reading trigger
attr HM_652E9A event-on-change-reading state

Gruß Otto

[dadoc]

Hallo Frank & Otto,
... und danke fürs Kümmern.
Ich habe jetzt gerade noch einen zweiten, baugleichen, nagelneuen Schalter konfiguriert, verhält sich identisch.
Ich glaube, es liegt am notify. Sobald ich es deaktiviere, sendet die Taste brav ein einziges Mal.
Aber selbst wenn ich es stark vereinfacht reinnehme:

Code Auswählen Erweitern

HM_Switch_Btn_.*:.*  {
    my $HM_Switch_Nr = substr($NAME,14,2);
    my $Dimmer_nummer = "Dimmer_".$HM_Switch_Nr;
    my $Dimmer_state = ReadingsVal($Dimmer_nummer, "state", "");
    my $Press_Event = $EVENT;
    if ($Press_Event = " Short") {
if ($Dimmer_state eq "off") {
fhem "set $Dimmer_nummer on"}
else {
fhem "set $Dimmer_nummer off" }
}
}
bleibt das Problem bestehen. Es muss irgendwie an der Regex liegen. Aber nach dem, was ich gelesen habe, wird ,,Zeilenende" bei notifies intern ergänzt, sodass ,, Short" ja nur einmal interpretiert werden dürfte?
Aber selbst wenn nicht ist mir unklar, wie ein notify einen Schalter zum Mehrfachsenden bewegen könnte?
Mit dem HM-Oled-Schalter läuft dasselbe notify BTW problemlos.
Grüße
Martin

[dadoc]

Der zweite Versuchsschalter ist BTW ungepeered.
Habe attr HM_652E9A event-on-change-reading state gesetzt, das Problem bleibt (sendet in unregelmäßiger Reihenfolge, 1-, 2- oder 3-mal

[Otto123]

Das der Taster mehrfach sendet und das notify welches darauf reagiert sind doch zwei paar Schuhe. Ich sehe da bis jetzt keinen Zusammenhang.
Das notify reagiert auf die Events, es erzeugt keine mit dem HM_Switch_Btn

Ich würde das regExp vom notify so machen:

Code Auswählen Erweitern

HM_652E9A:HM_Switch_Btn_...Short und dies setzen

Code Auswählen Erweitern

attr HM_652E9A event-on-change-reading state

Mein Rat: mach parallel einfach ein neues notify zum Test und mach dort im Ausführungsteil nur {Log 1, "Irgendwas"}

Gruß Otto

[dadoc]

Danke Otto,
wie erklärt es sich aber dann, dass der Taster reproduzierbar nur einmal sendet, sobald das notify weg ist?
Was die Regex betrifft: Ich hatte ja den Ehrgeiz, in einem notify sowohl Short als auch Long (fürs Dimmen) als auch LongRelease abzudecken, was mit den anderen HM Schaltern ja auch funktioniert. Daher HM_Switch_Btn_.*:.*
So sieht es aus:

Code Auswählen Erweitern

HM_Switch_Btn_.*:.*  {
    my $HM_Switch_Nr = substr($NAME,14,2);
    my $Dimmer_nummer = "Dimmer_".$HM_Switch_Nr;
    my $Ramp_direction = ReadingsVal("dimupdown_dummy", "state", "");
    my $Ramp_active = ReadingsVal("ramp_active_dummy", "state", "");
my $Dimmer_state = ReadingsVal($Dimmer_nummer, "state", "");
my $Press_Event = $EVENT;
    if ($Press_Event =~ "Long " && $Ramp_direction eq "dimdown" && $Ramp_active eq "no") {
fhem "set $Dimmer_nummer dim 0 7";
fhem "set ramp_active_dummy yes"}
elsif ($Press_Event =~ "LongRelease" and $Ramp_direction eq "dimdown") {
fhem "set $Dimmer_nummer timer 0";
fhem "set dimupdown_dummy dimup";
fhem "set ramp_active_dummy no"}
elsif ($Press_Event =~ "LongRelease" and $Ramp_direction eq "dimup") {
fhem "set $Dimmer_nummer timer 0" ;
fhem "set dimupdown_dummy dimdown" ;
fhem "set ramp_active_dummy no" }
elsif ($Press_Event =~ "Long " && $Ramp_direction eq "dimup" && $Ramp_active eq "no") {
fhem "set $Dimmer_nummer dim93% 7";
fhem "set ramp_active_dummy yes" }
elsif ($Press_Event =~ " Short") {
if ($Dimmer_state eq "off") {
fhem "set $Dimmer_nummer on"}
else {
fhem "set $Dimmer_nummer off" }
}
}
Werde jetzt aber mal mit Deiner Anregung mit ( ShortlLong |LongRelease) experimentieren.

[dadoc]

Für mich liegt der Hase begraben in (aus dem notify-Eintrag im Wiki):

Das Suchmuster wird notify intern um das Zeichen ^ (beginnt mit) und das Zeichen $ (endet mit) ergänzt

Ich habe den Eindruck, dass das zumindest mit diesem speziellen Sender nicht so funktioniert (wie geschrieben: mit dem Oled-Sender dagegen problemlos).
Ich habe jetzt

Code Auswählen Erweitern

elsif ($Press_Event ~= " Short")
was für mich übersetzt "ein Event, der Leerzeichen, gefolgt von Short, gefolgt von Zeilenende" bedeutet, geändert in

Code Auswählen Erweitern

elsif ($Press_Event = ".*Short") {
übersetzt "irgendwas , gefolgt von Short, gefolgt von Zeilenende", und Zzzack!!! Keine Mehrfachsendungen mehr.
Kann ich mir (mit meinem doch sehr beschränkten Programmierwissen) nur so erklären, dass beim ~= eben doch kein $ ergänzt wird - oder, wahrscheinlicher, dass dieser Sender (und andere, ähnliche, mit denen die Leute ähnliche Probleme haben) das Zeilenende auf eine andere Weise übermittelt, oder?

[Otto123]

Danke Otto,
wie erklärt es sich aber dann, dass der Taster reproduzierbar nur einmal sendet, sobald das notify weg ist?

Ich würde Dir gern helfen und versuchen herauszufinden was genau passiert - ich will nicht die Welt retten.
Ich meine damit, Du zeigst das Problem, dass der Eventmonitor dir mehrere Events des Button HM_Switch_Btn_11 zeigt. Das liegt ziemlich eindeutig daran, dass er mehrfach sendet.
Du sagst jetzt, die dreifachen Events im Eventmonitor tauchen nicht mehr auf wenn das notify weg ist?
ich will nicht dein ganzes notify verstehen, deswegen möchte ich Dir zeigen, dass es möglich ist diese mehrfachen Events zu ignorieren. Du machst aber was ganz anderes als ich geraten habe. Du willst dein finales Problem lösen 

Also mach doch bitte mal

Code Auswählen Erweitern

attr HM_652E9A event-on-change-reading state
define n_testOtto notify HM_652E9A:HM_Switch_Btn_...Short {Log 1, "Hier steht hoffentlich pro Tastendruck nur ein Eintrag"}

Dann fällt es mir wie Schuppen aus den Haaren: In deinem notify feuerst Du auf FS20 Sender richtig? (das u.a. einen FS20-Dimmer ein- und ausschaltet.)

Damit störst Du den Funk (868 MHz) des Homematic durch Funkfeuer über den FS20 Sender und das Ack kommt nicht mehr. Er versucht es mehrfach und hat Erfolg.

Gruß Otto

[Pfriemler]

Meine Güte - na klar. Respekt, den Zusammenhang hatte ich auch nicht hergestellt, aber es klingt sehr plausibel.
Ich habe so was ähnliches an ganz anderer Stelle und da ist nicht einmal das Funkfeuer schuld, aber seit ich eine kurze Verzögerung eingebaut habe, tut es sicher.

[dadoc]

Hallo Otto,

Also mach doch bitte mal

Code Auswählen Erweitern

attr HM_652E9A event-on-change-reading state
define n_testOtto notify HM_652E9A:HM_Switch_Btn_...Short {Log 1, "Hier steht hoffentlich pro Tastendruck nur ein Eintrag"}

Werde ich heute Abend mal ausprobieren.

Dann fällt es mir wie Schuppen aus den Haaren: In deinem notify feuerst Du auf FS20 Sender richtig? (das u.a. einen FS20-Dimmer ein- und ausschaltet.)

Ja, das notify lässt (in diesem Fall) einen FS20-Steckdosendimmer über den CUL868 schalten. Seltsamerweise tritt dieses Problem aber nur mit diesem Schaltertyp und diesem Dimmertyp auf. Wenn ich mit demselben notify über einen Oled-Schalter (ebenfalls HM) meine Phasenanschnittsdimmer (ebenfalls FS20: fs20di) über den CUL868 schalte bzw. dimme, funktioniert das perfekt.

Code Auswählen Erweitern

Damit störst Du den Funk (868 MHz) des Homematic durch Funkfeuer über den FS20 Sender und das Ack kommt nicht mehr. Er versucht es mehrfach und hat Erfolg.
Das klingt einleuchtend. Allerdings habe ich viele FS20-Geräte, die ich mit HM-Sendern steuere, und bislang hat es bei keinem Probleme gegeben. Eben nur bei diesem Steckdosendimmer. Ich muss mal schauen, ob ich noch einen anderen Dimmer habe, um das weiter einzukreisen...

[dadoc]

Hallo Otto,
Dein Test-Notify in dieser Form

Code Auswählen Erweitern

HM_653129:HM_Switch_Btn_...Short  {Log 1, fhem "set Dimmer_02 toggle"}
bewirkt, dass der Dimmer pro Tastendruck (ungepeered) innerhalb ca. 1 Sekunde ein-aus-ein bzw. aus-ein-aus schaltet.
Im Log sieht das so aus:

Code Auswählen Erweitern

2018.08.27 23:11:03 3: HM_653129_notify_1 return value: HASH(0x490cc18)
2018.08.27 23:11:03 3: FS20 set Dimmer_02 toggle
[Mon Aug 27 23:11:03 2018] fhem.pl: Use of uninitialized value $text in concatenation (.) or string at fhem.pl line 951.
2018.08.27 23:11:03 1:
2018.08.27 23:11:03 3: HM_653129_notify_1 return value: HASH(0x4ab7508)
2018.08.27 23:11:03 3: FS20 set Dimmer_02 toggle
[Mon Aug 27 23:11:03 2018] fhem.pl: Use of uninitialized value $text in concatenation (.) or string at fhem.pl line 951.
2018.08.27 23:11:03 1:
2018.08.27 23:11:03 3: HM_653129_notify_1 return value: HASH(0x48c0108)
2018.08.27 23:11:03 3: FS20 set Dimmer_02 toggle
[Mon Aug 27 23:11:03 2018] fhem.pl: Use of uninitialized value $text in concatenation (.) or string at fhem.pl line 951.
2018.08.27 23:11:03 1:
Außer, man ist mit dem Sender maximal 2 Meter vom hmusb entfernt. Dann schaltet es immer nur einfach. Das würde Deinen Verdacht bestätigen, allerdings gäbe es dann massive Unterschiede in Sachen störungsfreiem (im Sinne von FS20-immunem) Empfang zwischen diesen 6fach-Sendern und etwa dem Oled-Sender.

Weitere Erkenntnis für mein eigenes notify:
elsif ($Press_Event =~ " Short") -> funktioniert perfekt
elsif ($Press_Event =~ ".*Short") -> schaltet ein und sofort wieder aus, müsste aber IMO eigentlich genauso funktionieren.

Das ist für mich schon eine harte Nuss...

[Pfriemler]

Das Problem ist weniger der Steckdosendimmer als vielmehr vielleicht der Handsender. Der ist für seine schlechte Empfangsqualität berüchtigt. Man kann fast sicher mit gepeerten Aktoren und zunehmender Reichweite provozieren, dass der Aktor zwar noch sicher schaltet, der Handsender aber nur noch rot die ausbleibende Quittung bemeckert - schlicht weil er die nicht mehr hört.
Wenn nun noch das Funkfeuer zum FS20 dazu kommt...

Hast du mal testweise versucht, die Befehle an den Dimmer zu verzögern (sleep 1 sollte reichen)?

[Otto123]

Machst Du mal bitte ein

Code Auswählen Erweitern

list HM_652E9A

Sicher hast Du dies vergessen:

Code Auswählen Erweitern

attr HM_652E9A event-on-change-reading state

[dadoc]

Machst Du mal bitte ein

Code Auswählen Erweitern

list HM_652E9A

Code Auswählen Erweitern

Internals:
   DEF        653129
   IODev      hmusb
   LASTInputDev hmusb
   MSGCNT     465
   NAME       HM_653129
   NOTIFYDEV  global
   NR         1371
   NTFY_ORDER 50-HM_653129
   STATE      HM_Switch_Btn_11 Short
   TYPE       CUL_HM
   channel_01 HM_Switch_Btn_11
   channel_02 HM_653129_Btn_02
   channel_03 HM_653129_Btn_03
   channel_04 HM_653129_Btn_04
   channel_05 HM_653129_Btn_05
   channel_06 HM_653129_Btn_06
   hmusb_MSGCNT 465
   hmusb_RAWMSG E653129,0000,13396DCD,FF,FFB3,3EA2406531294242420137
   hmusb_RSSI -77
   hmusb_TIME 2018-08-28 09:18:59
   lastMsg    No:3E - t:40 s:653129 d:424242 0137
   protLastRcv 2018-08-28 09:18:59
   protRcv    465 last_at:2018-08-28 09:18:59
   protSnd    421 last_at:2018-08-28 09:18:59
   protState  CMDs_done
   rssi_at_hmusb cnt:465 min:-93 max:-51 avg:-66.99 lst:-77
   READINGS:
     2018-08-26 14:03:11   CommandAccepted yes
     2018-08-26 14:03:44   D-firmware      1.2
     2018-08-26 14:03:44   D-serialNr      OEQ2114125
     2018-08-26 14:03:44   PairedTo        0x424242
     2018-08-26 14:03:44   R-pairCentral   0x424242
     2018-08-26 14:03:44   RegL_00.        02:01 0A:42 0B:42 0C:42 18:00 00:00
     2018-08-28 09:18:59   battery         ok
     2018-08-28 09:18:59   state           HM_Switch_Btn_11 Short
   helper:
     HM_CMDNR   62
     mId        00A9
     regLst     ,0
     rxType     28
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +653129,00,01,00
       nextSend   1535440739.90187
       prefIO     
       rxt        2
       vccu       
       p:
         653129
         00
         01
         00
     mRssi:
       mNo        3E
       io:
         hmusb:
           -75
           -75
     prt:
       bErr       0
       sProc      0
       sleeping   0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
     rpt:
       IO         hmusb
       flg        A
       ts         1535440739.82332
       ack:
         HASH(0x43639c0)
         3E800242424265312900
     rssi:
       at_hmusb:
         avg        -66.9935483870969
         cnt        465
         lst        -77
         max        -51
         min        -93
     tmpl:
Attributes:
   IODev      hmusb
   autoReadReg 4_reqStatus
   event-on-change-reading state
   expert     2_raw
   firmware   1.2
   model      HM-PB-6-WM55
   room       CUL_HM,Settings
   serialNr   OEQ2114125
   subType    remote
   webCmd     getConfig:clear msgEvents

(Ist der andere, identische Schalter)

Sicher hast Du dies vergessen:

Code Auswählen Erweitern

attr HM_652E9A event-on-change-reading state

Ja, sorry, hatte es bei dem anderen Versuchsschalter gesetzt. Jetzt sieht es bei einmaligem kurzen Druck z.B. so aus:
EDIT: Da war parallel noch mein eigenes notify active, daher quatsch...
So,sieht es jetzt aus

Code Auswählen Erweitern

2018.08.28 09:32:46 3: HM_653129_notify_1 return value: HASH(0x48f60b8)
2018.08.28 09:32:46 3: FS20 set Dimmer_02 toggle
[Tue Aug 28 09:32:46 2018] fhem.pl: Use of uninitialized value $text in concatenation (.) or string at fhem.pl line 951.
2018.08.28 09:32:46 1:
2018.08.28 09:32:46 3: HM_653129_notify_1 return value: HASH(0x47e2e68)
2018.08.28 09:32:46 3: FS20 set Dimmer_02 toggle
[Tue Aug 28 09:32:46 2018] fhem.pl: Use of uninitialized value $text in concatenation (.) or string at fhem.pl line 951.
2018.08.28 09:32:46 1:
2018.08.28 09:32:46 3: HM_653129_notify_1 return value: HASH(0x3e66288)
2018.08.28 09:32:46 3: FS20 set Dimmer_02 toggle
[Tue Aug 28 09:32:46 2018] fhem.pl: Use of uninitialized value $text in concatenation (.) or string at fhem.pl line 951.
2018.08.28 09:32:46 1:

[dadoc]

Hast du mal testweise versucht, die Befehle an den Dimmer zu verzögern (sleep 1 sollte reichen)?

Mit

Code Auswählen Erweitern

HM_653129:HM_Switch_Btn_...Short  {Log 1, sleep 1;; fhem "set Dimmer_02 toggle"}
sieht es auf den ersten Blick sehr gut aus, das muss ich heute Abend mal weiter testen.
Auch die concatenation wird so nicht mehr bemeckert:

Code Auswählen Erweitern

2018.08.28 09:37:00 3: HM_653129_notify_1 return value: HASH(0x45de338)
2018.08.28 09:37:01 1: 1
2018.08.28 09:37:01 3: FS20 set Dimmer_02 toggle