Homematic Vierfach-Handsender schaltet doppelt bzw. mehrfach

[Gisbert]

Hallo,

ich habe einen Vierfach-Handsender von Homematic als Schlüsselanhänger zur Schaltung eines Garagentors.
Das Device ist über eine VCCU mit AES-Verschlüsselung an Fhem angebunden. Ein notify registriert den Tastendruck und schaltet dann ein Relais des Torantriebs.

Leider kommt es vor, dass nur ein kurzer Tastendruck (short) mehrfach ausgeführt wird; d.h. das Tor startet und stoppt augenblicklich wieder.
Wie kann ich dieses Verhalten ändern?

Viele​ Grüße​ Gisbert​

List des Logfiles:

Code Auswählen Erweitern

2017-11-20_19:59:42 Handsender battery: ok
2017-11-20_19:59:42 Handsender rssi_at_HMLAN1: -93
2017-11-20_19:59:42 Handsender CMDs_done
2017-11-20_19:59:42 Handsender Handsender.03 Short
2017-11-20_19:59:43 Handsender battery: ok
2017-11-20_19:59:43 Handsender rssi_at_HMLAN1: -93
2017-11-20_19:59:43 Handsender CMDs_done
2017-11-20_19:59:43 Handsender Handsender.03 Short

Der Vierfach-Handsender:

Code Auswählen Erweitern

defmod Handsender CUL_HM 5AEA5B
attr Handsender IODev HMLAN1
attr Handsender IOgrp VCCU:HMLAN1
attr Handsender autoReadReg 4_reqStatus
attr Handsender devStateIcon Handsender.03.Short:fts_garage
attr Handsender expert 2_raw
attr Handsender firmware 1.1
attr Handsender group remote
attr Handsender icon it_remote
attr Handsender model HM-RC-4-3
attr Handsender msgRepeat 0
attr Handsender room CUL_HM,Mobile,Rollladen
attr Handsender rssiLog 1
attr Handsender serialNr OEQ0799032
attr Handsender subType remote
attr Handsender webCmd getConfig:clear msgEvents

setstate Handsender Handsender.03 Short
setstate Handsender 2017-11-18 07:22:11 .D-devInfo 040000
setstate Handsender 2017-11-18 07:22:11 .D-stc 40
setstate Handsender 2017-11-20 19:59:55 .protLastRcv 2017-11-20 19:59:55
setstate Handsender 2017-11-18 07:27:49 CommandAccepted yes
setstate Handsender 2017-11-18 07:22:11 D-firmware 1.1
setstate Handsender 2017-11-18 07:22:11 D-serialNr OEQ0799032
setstate Handsender 2017-11-18 07:23:20 PairedTo 0x257643
setstate Handsender 2017-11-18 07:00:28 R-pairCentral 0x257643
setstate Handsender 2017-11-18 07:23:20 RegL_00. 02:01 0A:25 0B:76 0C:43 18:00 00:00
setstate Handsender 2017-11-18 07:02:04 aesCommToDev ok
setstate Handsender 2017-11-18 07:02:04 aesKeyNbr 00
setstate Handsender 2017-11-20 19:59:55 battery ok
setstate Handsender 2017-11-20 19:59:55 rssi_at_HMLAN1 -94
setstate Handsender 2017-11-18 16:17:26 rssi_at_myHmUARTLGW -85
setstate Handsender 2017-11-20 19:59:55 state Handsender.03 Short


Das dummy Device:

Code Auswählen Erweitern

defmod myRollladenGarage dummy
attr myRollladenGarage devStateIcon Hochfahren:time_manual_mode Runterfahren:time_manual_mode Stop:time_manual_mode Lücke:time_manual_mode
attr myRollladenGarage eventMap up:Hochfahren stop:Stop slit:Lücke down:Runterfahren
attr myRollladenGarage group Rollladen
attr myRollladenGarage icon fts_garage
attr myRollladenGarage readingList ipAdresse
attr myRollladenGarage room Mobile,Rollladen
attr myRollladenGarage setList ipAdresse up:noArg down:noArg stop:noArg slit:noArg
attr myRollladenGarage webCmd Hochfahren:Stop:Lücke:Runterfahren

Das notify:

Code Auswählen Erweitern

defmod notifyRollladenControl notify myRollladen.*(up|down|stop|slit) { rollladenControl($NAME,ReadingsVal("$NAME","ipAdresse",0),$EVTPART0) }
attr notifyRollladenControl group Rollladen
attr notifyRollladenControl icon fts_shutter_automatic
attr notifyRollladenControl room Rollladen

[martinp876]

Ich sehe das eventonchangereading .* nicht. Das sollte man überall - zumindest in culhm vorsehen.
Ist so auch im Wiki empfohlen

[Pfriemler]

Liefere bitte mal echte Lists des Handsenderkanals, nicht die raw def oder fhem.cfg-Auszug. Und das Notify, das den Tastendruck verarbeitet.

Der rssi ist sehr schlecht, die Quittung dürfte kaum ankommen, sicher viele resends. Sollte zwar keine Probleme machen aber ... ?

[Otto123]

In Ergänzung: Schau Dir den Eventmonitor an, der erklärt meistens sehr bildlich das Problem mit mehrfach Events und Auslösung.

Gruß Otto

[Gisbert]

Hallo zusammen,

der Hinweis auf event-on-change-reading hat mich auf die richtige Spur gebracht, auch wenn es nicht die Lösung war.
Ich hab den Eventmonitor bemüht und geschaut, welche Events beim Drücken eines Knopfes auf der Fernbedienung erscheinen.

Was letztlich zum Erfolg geführt hat, war event-min-interval - ohne event-on-change-reading.
Im Device wurde das Attribut event-min-interval auf 2 Sekunden gesetzt.
Dadurch wird ein Event für dieses Attribut für 2 Sekunden unterbunden, und folglich sieht notify kein Event innerhalb dieser 2 Sekunden und löst nicht aus, auch wenn man den Knopf der Fernbedienung mehrfach bedient.

Anscheinend ist es so, dass die VCCU / HMLAN-Adapter einen Befehl mehrfach, aber nicht immer mehrfach, raussendet, was dann beim Garagentor mit Toggle-Funktion als Rauf-Stop-Runter-Stop-... ankommt.
Ich werde das Ganze mal beobachten, ob die beschriebene Lösung auch langfristig funktioniert.
Ich hab noch einen HM-MOD-UART, den ich in oder in die Nähe der Garage plazieren werde; damit müsste der RSSI dann deutlich besser werden.

Mit dem event-min-interval habe ich zumindest eine Lösung, wie seht ihr das?
Viele Grüße Gisbert

Anbei das Listdes Handsendekanals:

Code Auswählen Erweitern

Internals:
   CFGFN      ./FHEM/HomematicAktorenSensoren.cfg
   DEF        5AEA5B04
   NAME       Handsender.04
   NOTIFYDEV  global
   NR         317
   NTFY_ORDER 50-Handsender.04
   STATE      Short 1_145 (to VCCU)
   TYPE       CUL_HM
   chanNo     04
   device     Handsender
   READINGS:
     2017-11-18 07:26:43   R-sign          on
     2017-11-18 07:26:43   RegL_01.        04:10 08:01 09:00 00:00
     2017-11-21 10:41:45   state           Short 1_145 (to VCCU)
     2017-11-21 10:41:45   trigger         Short_145
     2017-11-21 10:41:45   trigger_cnt     145
   helper:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     role:
       chn        1
     tmpl:
Attributes:
   event-min-interval .*:2
   group      remote
   icon       fts_garage
   model      HM-RC-4-3
   peerIDs    00000000,
   room       CUL_HM

und das notify, welches den Tastendruck verarbeitet (beim notify ist eigentlich egal, ob ich den Befehl für Hochfahren, Runterfahren oder Stoppen benutze, da es sich bei der Garagentorschaltung um Toggle-Schaltung handelt):

Code Auswählen Erweitern

Internals:
   CFGFN      ./FHEM/HomematicAktorenSensoren.cfg
   DEF        Handsender.04:trigger_cnt:.* set myRollladenGarage Hochfahren
   NAME       notify.Garage
   NOTIFYDEV  Handsender.04
   NR         319
   NTFY_ORDER 50-notify.Garage
   REGEXP     Handsender.04:trigger_cnt:.*
   STATE      active
   TYPE       notify
   READINGS:
     2017-11-21 12:46:30   state           active
Attributes:
   icon       fts_garage
   room       CUL_HM

[Pfriemler]

event-on-change-reading bietet sich so oder so trotzdem an.

Erkläre doch nochmal, was genau Du im Eventmonitor gesehen hast. Hat EIN Tastendruck MEHRERE Events ausgelöst? Das ist eigentlich ungewöhnlich, denn selbst wenn die Fernbedienung mehrmals Telegramme sendet, weil sie die Quittung vermisst (nur falls überhaupt ein ACK-Partner defniert ist oder per se aktiv, also die LED an der Fernbedienung erst orange, dann grün leuchtet), dann erkennt FHEM das und löst nicht mehrfache Events aus.
Anders sieht die Sachlage aus, wenn die Fernbedienung einen Wackelkontakt im Taster hat (und also mehrere Shorts mit steigendem trigger_cnt sendet) oder ein ungeduldiger Benutzer mehrmals auf den Knopf drückt "bis was passiert". Genau dafür ist event-min-interval dann die richtige Lösung.

Anscheinend ist es so, dass die VCCU / HMLAN-Adapter einen Befehl mehrfach, aber nicht immer mehrfach, raussendet, was dann beim Garagentor mit Toggle-Funktion als Rauf-Stop-Runter-Stop-... ankommt.

Also wenn ich das richtig interpretiere, nutzt Du einen WLAN-basierten Aktor für die Steuerung. Ob FHEM dort mehrmals Kommandos hinschickt, weiß ich nicht. Was von der Fernbedienung hereinkommt, wird wie oben genannt interpretiert: Resends wegen Funkproblemen erzeugen keine zusätzlichen Events, Wackler oder ungeduldige Benutzer schon.

[Gisbert]

Hallo Pfriemler,

im Eventmonitor (gefiltert auf Handsender) erscheint pro Knopfdruck ein Event, ich hab insgesamt 3-mal gedrückt, mit ca. 5 Sekunden Abstand.
Da ich das Garagentor jetzt nicht dauernd auf und zu fahren wollte, hab ich den Button 03 / Handsender.03 benutzt, der von keinem notify überwacht wird.

Code Auswählen Erweitern

2017-11-21 18:58:20 readingsGroup Battery.State Handsender.battery: image/svg+xml                                     
2017-11-21 18:58:20 readingsGroup HomeMatic.Components Handsender.battery: ok
2017-11-21 18:58:20 CUL_HM Handsender battery: ok
2017-11-21 18:58:20 CUL_HM Handsender rssi_at_myHmUARTLGW: -62
2017-11-21 18:58:20 CUL_HM Handsender CMDs_done
2017-11-21 18:58:20 CUL_HM Handsender Handsender.03 Short
2017-11-21 18:58:20 CUL_HM Handsender.03 Short 1_87 (to VCCU)
2017-11-21 18:58:20 CUL_HM Handsender.03 trigger: Short_87
2017-11-21 18:58:20 CUL_HM Handsender.03 trigger_cnt: 87
2017-11-21 18:58:20 CUL_HM Handsender rssi_at_HMLAN1: -99
2017-11-21 18:58:26 readingsGroup Battery.State Handsender.battery: image/svg+xml                                     
2017-11-21 18:58:26 readingsGroup HomeMatic.Components Handsender.battery: ok
2017-11-21 18:58:26 CUL_HM Handsender battery: ok
2017-11-21 18:58:26 CUL_HM Handsender rssi_at_myHmUARTLGW: -55
2017-11-21 18:58:26 CUL_HM Handsender CMDs_done
2017-11-21 18:58:26 CUL_HM Handsender Handsender.03 Short
2017-11-21 18:58:26 CUL_HM Handsender.03 Short 1_88 (to VCCU)
2017-11-21 18:58:26 CUL_HM Handsender.03 trigger: Short_88
2017-11-21 18:58:26 CUL_HM Handsender.03 trigger_cnt: 88
2017-11-21 18:58:26 CUL_HM Handsender rssi_at_HMLAN1: -92
2017-11-21 18:58:32 readingsGroup Battery.State Handsender.battery: image/svg+xml                                     
2017-11-21 18:58:32 readingsGroup HomeMatic.Components Handsender.battery: ok
2017-11-21 18:58:32 CUL_HM Handsender battery: ok
2017-11-21 18:58:32 CUL_HM Handsender rssi_at_myHmUARTLGW: -56
2017-11-21 18:58:32 CUL_HM Handsender CMDs_done
2017-11-21 18:58:32 CUL_HM Handsender Handsender.03 Short
2017-11-21 18:58:32 CUL_HM Handsender.03 Short 1_89 (to VCCU)
2017-11-21 18:58:32 CUL_HM Handsender.03 trigger: Short_89
2017-11-21 18:58:32 CUL_HM Handsender.03 trigger_cnt: 89
2017-11-21 18:58:33 CUL_HM Handsender rssi_at_HMLAN1: -93

Auch bei den Versuchen heute nachmittag habe ich keine Mehrfachevents gesehen, außer ich habe in schneller Reihenfolge einen Knopf gedrückt.

event-on-change-reading hab ich ausprobiert, auch in Kombination mit event-min-interval, was aber Events, die in schneller Reihenfolgen (kleiner als die gesetzte Zeit) reinkommen, nicht unterdrückt hat.
Nur event-min-interval führt hingegen zum Erfolg und blockiert events, deren Abstand kleiner als die definierte Zeitspanne ist.

Ich tendiere zum Wackelkontakt im Taster, denn es trat immer nur beim 1. Druck oder max. 2. Druck auf, anschließend hatte es auch ohne das gesetzte Attribut funktioniert.
Ein ungeduldigen Daumen kann ich nicht gänzlich ausschließen, halte ich aber für eher unwahrscheinlich; zweimal kurz hintereinander habe ich definitiv nicht gedrückt.
Wie dem auch sei, mit dem Attribut event-min-interval hab ich eine Lösung gefunden.

Der am Wlan hängende Adapter myHmUARTLGW liegt im Moment neben dem Wlan-Router und hat deshalb gute rssi-Werte.
Es hängt aber definitiv nicht an diesem Device, das hatte ich nämlich zeitweise außer Betrieb; der Fehler mit der Mehrfachauslösung war trotzdem da.

Viele Grüße Gisbert

PS: Das Wiki zu den event-Attributen ist anscheinend nicht vollständig. Da traue ich mich aber nicht dran, da ich die Kombinationen der event-Attribute noch nicht durchschaut habe.

[Pfriemler]

Saubere Sache jetzt. Die Shorts vom Button werden zuerst vom myHmUARTLGW empfangen und dekodiert (dessen rssi-Werte hängt aber von der Entfernung zur Fernbedienung ab und hat mit der Nähe zum WLAN nicht die Bohne zu tun, oder was wolltest Du damit sagen?), später auch vom HMLAN1 (generieren aber keine doppelten Events).
Und ja: event-on-change-reading hilft in Deinem konkreten Fall nicht, aber es schadet auch so nicht es zu setzen. Spätestens bei der Überwachung von Aktoren und der Reaktion auf Zustandsänderungen sprechen wir uns dann wieder  .

[Gisbert]

Hallo Pfriemler, Otto und Martin,

ich melde mich nochmals wegen des gleichen Problems: Handsender schaltet doppelt, was beim Garagentor zum Anfahren und kurz danach zum Stoppen führt.

Ich war mutig und habe das Attribut des Senders auf 1 Sekunde gesetzt: attribute Handsender.04 event-min-interval .*:1.
Dies führte jedoch wieder zu Schwierigkeiten - offenbar ist eine Sekunde nicht lang genug.

Im Logfile ist ersichtlich, dass das reading trigger_cnt innerhalb einer Sekunde doppelt mit der gleichen Zahl auftaucht, was dann zu der doppelten Ausführung führt.
Kann das so richtig sein, und was könnte die Ursache sein?

Ich nutze einen HMLAN-Adapter, der an einer VCCU hängt; ich hab den AES-Schlüssel gesetzt.

Das Logfile mit teilweisen doppelten Einträgen (teilweise auch nur einfach, da hat es problemlos funktioniert):

Code Auswählen Erweitern

2017-11-27_13:20:55 Handsender battery: ok
2017-11-27_13:20:55 Handsender rssi_at_HMLAN1: -103
2017-11-27_13:20:55 Handsender CMDs_done
2017-11-27_13:20:55 Handsender Handsender.04 Short
2017-11-27_13:20:55 Handsender.04 Short 1_172 (to VCCU)
2017-11-27_13:20:55 Handsender.04 trigger: Short_172
2017-11-27_13:20:55 Handsender.04 trigger_cnt: 172
2017-11-27_13:20:56 Handsender battery: ok
2017-11-27_13:20:56 Handsender rssi_at_HMLAN1: -93
2017-11-27_13:20:56 Handsender CMDs_done
2017-11-27_13:20:56 Handsender Handsender.04 Short
2017-11-27_13:20:56 Handsender.04 Short 2_172 (to VCCU)
2017-11-27_13:20:56 Handsender.04 trigger: Short_172
2017-11-27_13:20:56 Handsender.04 trigger_cnt: 172
2017-11-27_13:21:02 Handsender battery: ok
2017-11-27_13:21:02 Handsender rssi_at_HMLAN1: -98
2017-11-27_13:21:02 Handsender CMDs_done
2017-11-27_13:21:02 Handsender Handsender.04 Short
2017-11-27_13:21:02 Handsender.04 Short 1_173 (to VCCU)
2017-11-27_13:21:02 Handsender.04 trigger: Short_173
2017-11-27_13:21:02 Handsender.04 trigger_cnt: 173
2017-11-27_13:21:09 Handsender battery: ok
2017-11-27_13:21:09 Handsender rssi_at_HMLAN1: -95
2017-11-27_13:21:09 Handsender CMDs_done
2017-11-27_13:21:09 Handsender Handsender.04 Short
2017-11-27_13:21:09 Handsender.04 Short 1_174 (to VCCU)
2017-11-27_13:21:09 Handsender.04 trigger: Short_174
2017-11-27_13:21:09 Handsender.04 trigger_cnt: 174
2017-11-27_13:21:59 Handsender battery: ok
2017-11-27_13:21:59 Handsender rssi_at_HMLAN1: -105
2017-11-27_13:21:59 Handsender CMDs_done
2017-11-27_13:21:59 Handsender Handsender.04 Short
2017-11-27_13:21:59 Handsender.04 Short 1_175 (to VCCU)
2017-11-27_13:21:59 Handsender.04 trigger: Short_175
2017-11-27_13:21:59 Handsender.04 trigger_cnt: 175
2017-11-27_13:22:01 Handsender battery: ok
2017-11-27_13:22:01 Handsender rssi_at_HMLAN1: -100
2017-11-27_13:22:01 Handsender CMDs_done
2017-11-27_13:22:01 Handsender Handsender.04 Short
2017-11-27_13:22:01 Handsender.04 Short 2_175 (to VCCU)
2017-11-27_13:22:01 Handsender.04 trigger: Short_175
2017-11-27_13:22:01 Handsender.04 trigger_cnt: 175
2017-11-27_13:22:04 Handsender battery: ok
2017-11-27_13:22:04 Handsender rssi_at_HMLAN1: -100
2017-11-27_13:22:04 Handsender CMDs_done
2017-11-27_13:22:04 Handsender Handsender.04 Short
2017-11-27_13:22:04 Handsender.04 Short 1_176 (to VCCU)
2017-11-27_13:22:04 Handsender.04 trigger: Short_176
2017-11-27_13:22:04 Handsender.04 trigger_cnt: 176
2017-11-27_13:22:05 Handsender battery: ok
2017-11-27_13:22:05 Handsender rssi_at_HMLAN1: -97
2017-11-27_13:22:05 Handsender CMDs_done
2017-11-27_13:22:05 Handsender Handsender.04 Short
2017-11-27_13:22:05 Handsender.04 Short 2_176 (to VCCU)
2017-11-27_13:22:05 Handsender.04 trigger: Short_176
2017-11-27_13:22:05 Handsender.04 trigger_cnt: 176
2017-11-27_13:22:10 Handsender battery: ok
2017-11-27_13:22:10 Handsender rssi_at_HMLAN1: -106
2017-11-27_13:22:10 Handsender CMDs_done
2017-11-27_13:22:10 Handsender Handsender.04 Short
2017-11-27_13:22:10 Handsender.04 Short 1_177 (to VCCU)
2017-11-27_13:22:10 Handsender.04 trigger: Short_177
2017-11-27_13:22:10 Handsender.04 trigger_cnt: 177

List des Handsender(s).04:

Code Auswählen Erweitern

Internals:
   CFGFN      ./FHEM/HomematicAktorenSensoren.cfg
   DEF        5AEA5B04
   NAME       Handsender.04
   NOTIFYDEV  global
   NR         317
   NTFY_ORDER 50-Handsender.04
   STATE      Short 1_177 (to VCCU)
   TYPE       CUL_HM
   chanNo     04
   device     Handsender
   READINGS:
     2017-11-18 07:26:43   R-sign          on
     2017-11-18 07:26:43   RegL_01.        04:10 08:01 09:00 00:00
     2017-11-27 13:22:10   state           Short 1_177 (to VCCU)
     2017-11-27 13:22:10   trigger         Short_177
     2017-11-27 13:22:10   trigger_cnt     177
   helper:
     BNO        177
     BNOCNT     1
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     role:
       chn        1
     tmpl:
Attributes:
   event-min-interval .*:1
   group      remote
   icon       fts_garage
   model      HM-RC-4-3
   peerIDs    00000000,
   room       CUL_HM

List des Handsender(s):

Code Auswählen Erweitern

Internals:
   CFGFN      ./FHEM/HomematicAktorenSensoren.cfg
   DEF        5AEA5B
   HMLAN1_MSGCNT 12
   HMLAN1_RAWMSG E5AEA5B,0000,8AB8BE80,FF,FF96,DAA2405AEA5B25764304B1
   HMLAN1_RSSI -106
   HMLAN1_TIME 2017-11-27 13:22:10
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     12
   NAME       Handsender
   NOTIFYDEV  global
   NR         312
   NTFY_ORDER 50-Handsender
   STATE      Handsender.04 Short
   TYPE       CUL_HM
   channel_01 Handsender.01
   channel_02 Handsender.02
   channel_03 Handsender.03
   channel_04 Handsender.04
   lastMsg    No:DA - t:40 s:5AEA5B d:257643 04B1
   protLastRcv 2017-11-27 13:22:10
   protSnd    12 last_at:2017-11-27 13:22:10
   protState  CMDs_done
   rssi_at_HMLAN1 max:-93 lst:-106 cnt:12 min:-106 avg:-99.41
   READINGS:
     2017-11-18 07:27:49   CommandAccepted yes
     2017-11-18 07:22:11   D-firmware      1.1
     2017-11-18 07:22:11   D-serialNr      OEQ0799032
     2017-11-18 07:23:20   PairedTo        0x257643
     2017-11-18 07:00:28   R-pairCentral   0x257643
     2017-11-18 07:23:20   RegL_00.        02:01 0A:25 0B:76 0C:43 18:00 00:00
     2017-11-18 07:02:04   aesCommToDev    ok
     2017-11-18 07:02:04   aesKeyNbr       00
     2017-11-27 13:22:10   battery         ok
     2017-11-27 13:22:10   rssi_at_HMLAN1  -106
     2017-11-23 19:17:57   rssi_at_myHmUARTLGW -95
     2017-11-27 13:22:10   state           Handsender.04 Short
   helper:
     HM_CMDNR   218
     mId        00D4
     rxType     28
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +5AEA5B,00,01,00
       nextSend   1511785330.53157
       rxt        2
       vccu       VCCU
       p:
         5AEA5B
         00
         01
         00
       prefIO:
         HMLAN1
         myHmUARTLGW
     mRssi:
       mNo        DA
       io:
         HMLAN1     -104
     prt:
       bErr       0
       sProc      0
       sleeping   0
       rspWait:
     q:
       qReqConf
       qReqStat
     role:
       dev        1
     rpt:
       IO         HMLAN1
       flg        A
       ts         1511785330.44602
       ack:
         HASH(0x2863ab8)
         DA80022576435AEA5B00
     rssi:
       at_HMLAN1:
         avg        -99.4166666666667
         cnt        12
         lst        -106
         max        -93
         min        -106
     tmpl:
Attributes:
   IODev      HMLAN1
   IOgrp      VCCU:HMLAN1,myHmUARTLGW
   autoReadReg 4_reqStatus
   devStateIcon Handsender.04.Short:fts_garage
   expert     2_raw
   firmware   1.1
   group      remote
   icon       it_remote
   model      HM-RC-4-3
   msgRepeat  0
   room       CUL_HM,Mobile,Rollladen
   rssiLog    1
   serialNr   OEQ0799032
   subType    remote
   webCmd     getConfig:clear msgEvents

List der VCCU (es hängt derzeit nur der HMLAN-Adapter dran):

Code Auswählen Erweitern

Internals:
   CFGFN      ./FHEM/HomematicAktorenSensoren.cfg
   DEF        257643
   HMLAN1_MSGCNT 283
   HMLAN1_RAWMSG E502FAD,0000,8ABA708C,FF,FF96,878670502FAD000000003A59
   HMLAN1_RSSI -106
   HMLAN1_TIME 2017-11-27 13:24:01
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     283
   NAME       VCCU
   NOTIFYDEV  global
   NR         251
   NTFY_ORDER 50-VCCU
   STATE      HMLAN1:ok,myHmUARTLGW:disconnected,
   TYPE       CUL_HM
   assignedIOs HMLAN1,myHmUARTLGW
   READINGS:
     2017-11-24 00:39:27   CommandAccepted yes
     2017-11-23 19:18:16   recentStateType ack
     2017-11-27 13:30:59   state           HMLAN1:ok,myHmUARTLGW:disconnected,
     2017-11-27 13:24:01   unknown_502FAD  received
     2017-11-18 14:41:09   unknown_505921  received
     2017-11-18 15:20:42   unknown_5759BF  received
     2017-11-18 14:40:48   unknown_586CBC  received
     2017-11-22 21:16:43   unknown_588464  received
     2017-11-24 07:36:33   unknown_5921DC  received
     2017-11-23 17:29:04   unknown_5922C2  received
     2017-11-22 07:26:56   unknown_592336  received
     2017-11-25 16:45:27   unknown_592339  received
     2017-11-23 16:48:24   unknown_5923BA  received
   helper:
     HM_CMDNR   21
     mId        FFF0
     rxType     1
     ack:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       prefIO
       vccu
       ioList:
         HMLAN1
         myHmUARTLGW
     mRssi:
       mNo
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf
       qReqStat
     role:
       chn        1
       dev        1
       vrt        1
     tmpl:
Attributes:
   IODev      HMLAN1
   IOList     HMLAN1,myHmUARTLGW
   expert     2_raw
   group      HMLAN
   hmKey      01:xxxxxxxxxxxxxxxxxxxxxxxxxxxx
   model      CCU-FHEM
   room       CUL_HM
   subType    virtual
   webCmd     virtual:update

Viele Grüße Gisbert

[Otto123]

Hi,

deine rssi Werte sind Unterirdisch - kleiner als -80 ist kritisch.
Ich vermute das der Handsender dann keine Quittung bekommt und Sendewiederholungen macht.

Ich habe eine ähnliche Konstellation aber noch nie ein Problem damit, bei mir wird definitiv hoch oder runter gefahren, damit merke ich das nicht.

Du  müssest eine Art Verriegelung einbauen, die hattest Du aber quasi mit der Zeit auch schon.

Ich habe

[Gisbert]

Hallo Otto,

vielen Dank für die Info.
Dann muss man die Werbeaussagen von Homematic bzgl. des Vierfachsenders und dessen Reichweite mit Vorsicht geniessen.

Sobald ich wieder ein Homematic Wlan-Gateway habe, werde ich es näher ans Garagentor positionieren.
Ich werde das Attribut event-min-interval auf .*:2 setzen; damit sollte die Mehrfachausführung unterbunden werden.

Viele Grüße Gisbert

[Otto123]

Hallo Gisbert,

ich habe da eine Idee, so habe ich das auch gemacht. Du peerst den Handsender (der ist doch jetzt ungepeert?) mit einem virtuellen Kanal deiner VCCU.

Dann kannst Du auf diesen virtuellen Kanal triggern anstatt auf den Handsender direkt, der würde sauber mit dem Handsender reden, wenn nicht erreicht dann sendet der nochmal und wenn erreicht dann ist gut.

Hier meine Notiz dazu : https://heinz-otto.blogspot.de/2016/07/garagentor-mit-fhem-bedienen.html weiter unten im Text siehst DU das peeren mit dem virtuellen Knopf der VCCU.

Ich komme mit meinen Handsender (HMLAN ist im 1 OG, dann ist Giebel bzw. Dach) ca. 40 meter die Straße entlang. Das finde ich ordentlich.

Gruß Otto

[Pfriemler]

deine rssi Werte sind Unterirdisch - kleiner als -80 ist kritisch.
Ich vermute das der Handsender dann keine Quittung bekommt und Sendewiederholungen macht.

Das wird so sein, aber das dürfte FHEM bzw. CUL_HM nicht dazu veranlassen, doppelte Events auszulösen.
Aber die Idee mit dem virtuellen Button wäre einen Versuch wert.

[martinp876]

Eventonchangereading .* Sollte immer gesetzt sein. Für culhm zumindest.
Wenn du Schalter direkt peerst wird eine Wiederholung an den Magnumkern erkannt. Das device reagiert nur einmal.
Du kannst als Trigger für das notify auch Trigger nutzen. Hier kommt eine Nummer mit welche bei jedem Druck einmal erhöht wird. Das Reading ändert sich also einmal je Druck. Doppelmeldungen werden von eventonchangereading gefiltert. Gut ist.

[Gisbert]

Hallo Otto und Martin,

ich habe die Handsenderkanäle jetzt mit der VCCU gepeert. Ich hab dazu 4 virtuelle Kanäle in der VCCU angelegt, und jeden Button des Handsenders mit einem virtuellen Kanal gepeert. Am Handsender wird jetzt ein Knopfdruck mit orange, dann grün quittiert.

Kann ich davon ausgehen, dass ich das Peeren richtig gemacht habe? Deine Beschreibung, aber auch die im Wiki habe ich nicht bis in letzte Detail verstanden. Insbesondere die wiederholt auftauchende "0" in den Definitionen hab ich nicht verstanden.

Das Attribut event-on-change-reading setze ich bei den Handsenderkanälen.

Das notify geht jetzt auf einen der virtuellen Kanäle.
Ich werde beobachten, wie sich das Verhalten beim Tastendruck entwickelt und später berichten, wie es aussieht.

Viele​ Grüße​ Gisbert​

[Pfriemler]

wird eine Wiederholung an den Magnumkern erkannt.

Da hat die Autokorrektur aber diesmal so zugeschlagen, dass ich den Sinn nicht mehr erkennen kann. "Aktoren"?

Das Attribut event-on-change-reading setze ich bei den Handsenderkanälen.

Genau dort.

Die 0 in peerChan hat schon seine Richtigkeit. Sie bedeutet, dass sich das Kommando auf den ausgewählten Kanal als Referenz bezieht - größere Zahlen adressieren die Kanäle in den Geräten direkt, was mehr Verwirrung schafft als hilft.

[Otto123]

Hallo Gisbert,

bei grüner Quittung hast Du alles richtig gemacht! 

Das peerChan ist ganz gut in der Doku erklärt -> https://fhem.de/commandref_DE.html#CUL_HMpeerChan
Die 0 wird verwendet, wenn beim peeren der Button direkt angegeben wird (zweites Beispiel)

Example:
set myRemote peerChan 2 mySwActChn single set #Peer zweiten Knopf mit Aktorkanal
set myRmtBtn peerChan 0 mySwActChn single set #myRmtBtn ist ein Knopf der Fernbedienung. '0' wird hier nicht verarbeitet
set myRemote peerChan 2 mySwActChn dual set #Verknüpfe Knöpfe 3 und 4
set myRemote peerChan 3 mySwActChn dual unset #Entferne Peering für Knöpfe 5 und 6
set myRemote peerChan 3 mySwActChn dual unset aktor #Entferne Peering für Knöpfe 5 und 6 nur im Aktor

Gruß Otto

[dadoc]

Hallo zusammen,
Ich hänge mich mal der Auffindbarkeit halber an diesen älteren Thread, weil ich genau (?) dasselbe Phänomen beobachte.

Das wird so sein, aber das dürfte FHEM bzw. CUL_HM nicht dazu veranlassen, doppelte Events auszulösen.

Nagelneuer HM-PB-6-WM55, Kanal 5 (von mir umnumeriert in 11) soll ein notify triggern, das u.a. einen FS20-Dimmer ein- und ausschaltet.
Der Channel ist mit einem virtuellen Button der vccu gepeert. Aber nur an wenigen Positionen der Wohnung kommt grün/ACK. Meist kommt rot, auch wenn ich mit dem Schalter in der Hand nur 5 Meter Luftlinie ohne Hindenisse vom HM-USBcfg entfernt bin. Und genau dann sendet jeder einzelne kurze Tastendruck auf Taste 5 dreifach (und triggert den Dimmer via notify sichtbar auf ein-aus-ein):

Code Auswählen Erweitern


2018-08-18 09:14:44 CUL_HM HM_652E9A HM_Switch_Btn_11 Short
2018-08-18 09:14:44 CUL_HM HM_Switch_Btn_11 Short 1_201 (to vccu)
2018-08-18 09:14:44 CUL_HM HM_Switch_Btn_11 trigger: Short_201
2018-08-18 09:14:45 CUL_HM HM_652E9A HM_Switch_Btn_11 Short
2018-08-18 09:14:45 CUL_HM HM_Switch_Btn_11 Short 2_201 (to vccu)
2018-08-18 09:14:45 CUL_HM HM_Switch_Btn_11 trigger: Short_201
2018-08-18 09:14:45 CUL_HM HM_652E9A HM_Switch_Btn_11 Short
2018-08-18 09:14:45 CUL_HM HM_Switch_Btn_11 Short 3_201 (to vccu)
2018-08-18 09:14:45 CUL_HM HM_Switch_Btn_11 trigger: Short_201

Was ich nicht verstehe: Die Kommunikation Schalter <_> vccu scheint ja zu funktionieren

Code Auswählen Erweitern

rssi_at_hmusb cnt:415 min:-91 max:-39 avg:-73.02 lst:-70
Aber selbst wenn nicht, verstehe ich Eure Antworten (s.o.) so, dass fhem dann nicht einfach mehrmals pro Sekunde senden sollte.

[Otto123]

Hi,

doch, wenn er versucht seinen Peer zu erreichen und er von ihm nichts zurück bekommt, wiederholt er.

Du musst einfach auf den Peer (Der Channel ist mit einem virtuellen Button der vccu gepeert. ) und nicht auf HM_Switch_Btn_11 selbst triggern, das war glaube ich die Idee!

Gruß Otto

[dadoc]

Hmmm, dann muss ich mein notify umbauen (ein universal-notify, um 12 FS20-Dimmer mit HM Schaltern über jeweils übereinstimmende Numerierung zu steuern) bzw. sehr viele Buttons umbenennen. Hätte mich halt mal interessiert, ob es für dieses merkwürdige Verhalten (kein ACK in 5 Metern Abstand und darauf mehrfach Senden) mittlerweile eine Erklärung gibt.

[Otto123]

Was fehlt Dir an Erklärung? Die nur 5 meter Abstand? Das kann alles mögliche sein. Man kann das maximal mit einem Satz wirklich begründen: die Funkverbindung ist schlecht oder die Störstrahlung ist hoch.
Alles andere wäre hellsehen.

Das mehrfache senden ist so by Design und macht auch Sinn. Meines Wissens kannst Du das nur sinnvoll verhindern
wenn Du gerade nicht peerst. Dann schickt er einmal in die Luft. Zumindest bei den Tastern sollte es genau so sein, unabhängig davon ob sie gepairt sind oder nicht.
Ich hoffe ich liege nicht falsch.

Gruß Otto

[dadoc]

Als ich das Problem festgestellt hatte, hatte ich den Kanal nicht gepeered. Nachdem ich diesen Thread gefunden hatte, habe ich ihn mit einem Button der vccu gepeered. Das Problem ist unverändert. Und wie gesagt, es scheint ja nicht wirklich so zu sein, dass der Schalter (und andere HM-Devices in weit abgelegeneren Standorten) grundsätzlich Verbindungsprobleme hat. Das macht mir Kopfzerbrechen.

[frank]

sniffen, wie im wiki beschrieben.
poste je ein list vom device, channel und vccu-channel.

ein eigener thread wäre sicher sinnvoller gewesen.

[Otto123]

Das würde jetzt bedeuten ich habe nicht Recht mit den Tastern, aber warum sollten die mehrfach senden?  Kann sein...

Du kannst die rrsi Werte loggen und anschauen. Ich habe dabei festgestellt: Ich bin ein wesentlicher Störfaktor. Also wenn Du das Ding in der Hand hältst ist das für den Funk schon mal nicht günstig.

So in der Art, musst Du natürlich anpassen:

Code Auswählen Erweitern

defmod FileLog_Rssi FileLog ./log/Rssi-%Y.log SensorAK:rssi_at_HMLAN1:.*|SensorAK:rssi_at_HMUART1:.*|SensorWG:rssi_at_HMLAN1:.*|SensorWG:rssi_at_HMUART1:.*


Gruß Otto

[dadoc]

sniffen, wie im wiki beschrieben.
poste je ein list vom device, channel und vccu-channel.

Ok, werde die Hausarbeiten erledigen, sobald ich wieder vor Ort bin.

ein eigener thread wäre sicher sinnvoller gewesen.

Hatte es überlegt, mich aber nach dem Vergleich der Ergebnisse Google vs. Suchfunktion der Forensoftware im Sinne kommender fhem-Generationen für ein Anhängen an den bestehenden Thread entschieden.

[dadoc]

Guten Morgen,
Sniffed (mal weiter (rot), mal näher (grün) am CUL):

Code Auswählen Erweitern

2018.08.20 22:53:14 0: HMLAN_Parse: hmusb R:E38E057   stat:0000 t:16D0B907 d:FF r:FFBB     m:69 8610 38E057 000000 0A50F5080040
2018.08.20 22:53:15 0: HMLAN_Send:  hmusb I:K
2018.08.20 22:53:16 0: HMLAN_Parse: hmusb V:03C7 sNo:JEQ0700605 d:1EBD70 O:424242 t:16D0BE97 IDcnt:0025 L:2 %
2018.08.20 22:53:16 1: RMDIR: ./restoreDir/save/2018-08-16
2018.08.20 22:53:18 0: HMLAN_Parse: hmusb R:E3679E4   stat:0000 t:16D0C856 d:FF r:FFC1     m:00 8470 3679E4 000000 00F636
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 3: FS20 set Dimmer_11 on
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:19 3: FS20 set Dimmer_11 off
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
2018.08.20 22:53:20 3: FS20 set Dimmer_11 on
2018.08.20 22:53:22 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D0D9BA d:FF r:FFAF     m:BD A640 652E9A 424242 051C
2018.08.20 22:53:23 3: FS20 set Dimmer_11 off
2018.08.20 22:53:23 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D0DB1E d:FF r:FFB0     m:BE A240 652E9A 424242 051C
2018.08.20 22:53:23 3: FS20 set Dimmer_11 on
2018.08.20 22:53:23 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D0DC82 d:FF r:FFB1     m:BF A240 652E9A 424242 051C
2018.08.20 22:53:23 3: FS20 set Dimmer_11 off
2018.08.20 22:53:27 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D0ED44 d:FF r:FFB1     m:C1 A240 652E9A 424242 051D
2018.08.20 22:53:28 3: FS20 set Dimmer_11 on
2018.08.20 22:53:28 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D0EEA8 d:FF r:FFB0     m:C2 A240 652E9A 424242 051D
2018.08.20 22:53:28 3: FS20 set Dimmer_11 off
2018.08.20 22:53:31 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D0FB50 d:FF r:FFAE     m:C3 A640 652E9A 424242 051E
2018.08.20 22:53:31 3: FS20 set Dimmer_11 on
2018.08.20 22:53:31 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D0FCB6 d:FF r:FFAE     m:C4 A240 652E9A 424242 051E
2018.08.20 22:53:31 3: FS20 set Dimmer_11 off
2018.08.20 22:53:32 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D0FE1A d:FF r:FFAD     m:C5 A240 652E9A 424242 051E
2018.08.20 22:53:32 3: FS20 set Dimmer_11 on
2018.08.20 22:53:35 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D10B77 d:FF r:FFAE     m:C6 A640 652E9A 424242 051F
2018.08.20 22:53:35 3: FS20 set Dimmer_11 off
2018.08.20 22:53:36 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D10CDD d:FF r:FFB0     m:C7 A240 652E9A 424242 051F
2018.08.20 22:53:36 3: FS20 set Dimmer_11 on
2018.08.20 22:53:36 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D10E41 d:FF r:FFB1     m:C8 A240 652E9A 424242 051F
2018.08.20 22:53:36 3: FS20 set Dimmer_11 off
2018.08.20 22:53:40 0: HMLAN_Send:  hmusb I:K
2018.08.20 22:53:41 0: HMLAN_Parse: hmusb V:03C7 sNo:JEQ0700605 d:1EBD70 O:424242 t:16D12042 IDcnt:0025 L:2 %
2018.08.20 22:56:05 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D355EC d:FF r:FFB1     m:C9 A640 652E9A 424242 0520
2018.08.20 22:56:05 3: FS20 set Dimmer_11 on
2018.08.20 22:56:06 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D35750 d:FF r:FFB0     m:CA A240 652E9A 424242 0520
2018.08.20 22:56:06 3: FS20 set Dimmer_11 off
2018.08.20 22:56:06 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D358B5 d:FF r:FFB1     m:CB A240 652E9A 424242 0520
2018.08.20 22:56:06 3: FS20 set Dimmer_11 on
2018.08.20 22:56:12 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D370AE d:FF r:FFB2     m:CC A640 652E9A 424242 0521
2018.08.20 22:56:12 3: FS20 set Dimmer_11 off
2018.08.20 22:56:13 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D37212 d:FF r:FFB0     m:CD A240 652E9A 424242 0521
2018.08.20 22:56:13 3: FS20 set Dimmer_11 on
2018.08.20 22:56:13 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D37377 d:FF r:FFB0     m:CE A240 652E9A 424242 0521
2018.08.20 22:56:13 3: FS20 set Dimmer_11 off
2018.08.20 22:56:18 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D38903 d:FF r:FFB1     m:CF 8440 652E9A 424242 4522
2018.08.20 22:56:18 3: FS20 set Dimmer_11 off 7
2018.08.20 22:56:19 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D38B19 d:FF r:FFB3     m:D1 8440 652E9A 424242 4522
2018.08.20 22:56:19 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D38C24 d:FF r:FFB1     m:D2 8440 652E9A 424242 4522
2018.08.20 22:56:19 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D38D2E d:FF r:FFB1     m:D3 8440 652E9A 424242 4522
2018.08.20 22:56:20 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D38E39 d:FF r:FFB3     m:D4 8440 652E9A 424242 4522
2018.08.20 22:56:20 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D38F44 d:FF r:FFB2     m:D5 8440 652E9A 424242 4522
2018.08.20 22:56:20 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3904F d:FF r:FFB1     m:D6 8440 652E9A 424242 4522
2018.08.20 22:56:21 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3915B d:FF r:FFB3     m:D7 8440 652E9A 424242 4522
2018.08.20 22:56:21 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D39265 d:FF r:FFB2     m:D8 8440 652E9A 424242 4522
2018.08.20 22:56:21 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D39370 d:FF r:FFB2     m:D9 8440 652E9A 424242 4522
2018.08.20 22:56:21 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3947B d:FF r:FFAF     m:DA A240 652E9A 424242 4522
2018.08.20 22:56:21 3: FS20 set Dimmer_11 timer 0
2018.08.20 22:56:22 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D395DF d:FF r:FFB0     m:DB A240 652E9A 424242 4522
2018.08.20 22:56:22 3: FS20 set Dimmer_11 timer 0
2018.08.20 22:56:25 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3A367 d:FF r:FFB2     m:DC 8440 652E9A 424242 4523
2018.08.20 22:56:25 3: FS20 set Dimmer_11 off 7
2018.08.20 22:56:26 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3A57D d:FF r:FFB2     m:DE 8440 652E9A 424242 4523
2018.08.20 22:56:26 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3A688 d:FF r:FFB2     m:DF 8440 652E9A 424242 4523
2018.08.20 22:56:26 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3A793 d:FF r:FFB1     m:E0 8440 652E9A 424242 4523
2018.08.20 22:56:26 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3A89D d:FF r:FFB2     m:E1 8440 652E9A 424242 4523
2018.08.20 22:56:27 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3A9A8 d:FF r:FFB3     m:E2 8440 652E9A 424242 4523
2018.08.20 22:56:27 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3AAB3 d:FF r:FFB1     m:E3 8440 652E9A 424242 4523
2018.08.20 22:56:27 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3ABBE d:FF r:FFB3     m:E4 8440 652E9A 424242 4523
2018.08.20 22:56:28 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3ACC8 d:FF r:FFB4     m:E5 8440 652E9A 424242 4523
2018.08.20 22:56:28 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3ADD3 d:FF r:FFB1     m:E6 8440 652E9A 424242 4523
2018.08.20 22:56:28 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3AEDE d:FF r:FFB0     m:E7 A240 652E9A 424242 4523
2018.08.20 22:56:28 3: FS20 set Dimmer_11 timer 0
2018.08.20 22:56:28 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3B042 d:FF r:FFB1     m:E8 A240 652E9A 424242 4523
2018.08.20 22:56:28 3: FS20 set Dimmer_11 timer 0
2018.08.20 22:56:29 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3B1A7 d:FF r:FFAE     m:E9 A240 652E9A 424242 4523
2018.08.20 22:56:29 3: FS20 set Dimmer_11 timer 0
2018.08.20 22:56:34 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3C3EA d:FF r:FFB3     m:EA 8440 652E9A 424242 4524
2018.08.20 22:56:34 3: FS20 set Dimmer_11 dim93% 7
2018.08.20 22:56:34 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3C600 d:FF r:FFB3     m:EC 8440 652E9A 424242 4524
2018.08.20 22:56:34 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3C70B d:FF r:FFB3     m:ED 8440 652E9A 424242 4524
2018.08.20 22:56:35 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3C815 d:FF r:FFB2     m:EE 8440 652E9A 424242 4524
2018.08.20 22:56:35 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3C920 d:FF r:FFB3     m:EF 8440 652E9A 424242 4524
2018.08.20 22:56:35 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3CA2B d:FF r:FFB4     m:F0 8440 652E9A 424242 4524
2018.08.20 22:56:35 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3CB36 d:FF r:FFB2     m:F1 8440 652E9A 424242 4524
2018.08.20 22:56:36 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3CD4B d:FF r:FFB3     m:F3 8440 652E9A 424242 4524
2018.08.20 22:56:36 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3CE56 d:FF r:FFB2     m:F4 8440 652E9A 424242 4524
2018.08.20 22:56:36 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3CF61 d:FF r:FFB2     m:F5 8440 652E9A 424242 4524
2018.08.20 22:56:37 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3D06C d:FF r:FFB1     m:F6 A240 652E9A 424242 4524
2018.08.20 22:56:37 3: FS20 set Dimmer_11 timer 0
2018.08.20 22:56:37 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3D1D0 d:FF r:FFB0     m:F7 A240 652E9A 424242 4524
2018.08.20 22:56:37 3: FS20 set Dimmer_11 timer 0
2018.08.20 22:56:37 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3D334 d:FF r:FFB0     m:F8 A240 652E9A 424242 4524
2018.08.20 22:56:37 3: FS20 set Dimmer_11 timer 0
2018.08.20 22:56:41 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3E1FD d:FF r:FFB3     m:F9 8440 652E9A 424242 4525
2018.08.20 22:56:41 3: FS20 set Dimmer_11 off 7
2018.08.20 22:56:42 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3E413 d:FF r:FFB1     m:FB 8440 652E9A 424242 4525
2018.08.20 22:56:42 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3E51E d:FF r:FFB3     m:FC 8440 652E9A 424242 4525
2018.08.20 22:56:42 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3E629 d:FF r:FFB1     m:FD 8440 652E9A 424242 4525
2018.08.20 22:56:43 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3E734 d:FF r:FFB1     m:FE 8440 652E9A 424242 4525
2018.08.20 22:56:43 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3E83E d:FF r:FFB3     m:FF 8440 652E9A 424242 4525
2018.08.20 22:56:43 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3E949 d:FF r:FFB1     m:00 8440 652E9A 424242 4525
2018.08.20 22:56:43 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3EA54 d:FF r:FFB2     m:01 8440 652E9A 424242 4525
2018.08.20 22:56:44 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3EB5F d:FF r:FFB1     m:02 8440 652E9A 424242 4525
2018.08.20 22:56:44 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3EC6A d:FF r:FFB2     m:03 8440 652E9A 424242 4525
2018.08.20 22:56:44 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3ED74 d:FF r:FFB2     m:04 8440 652E9A 424242 4525
2018.08.20 22:56:44 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3EE7F d:FF r:FFB2     m:05 8440 652E9A 424242 4525
2018.08.20 22:56:45 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3EF8A d:FF r:FFB2     m:06 8440 652E9A 424242 4525
2018.08.20 22:56:45 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3F095 d:FF r:FFB0     m:07 8440 652E9A 424242 4525
2018.08.20 22:56:46 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3F1A0 d:FF r:FFB4     m:08 8440 652E9A 424242 4525
2018.08.20 22:56:46 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3F2AA d:FF r:FFB2     m:09 8440 652E9A 424242 4525
2018.08.20 22:56:46 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3F3B5 d:FF r:FFB1     m:0A 8440 652E9A 424242 4525
2018.08.20 22:56:46 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3F4C0 d:FF r:FFAD     m:0B A240 652E9A 424242 4525
2018.08.20 22:56:46 3: FS20 set Dimmer_11 timer 0
2018.08.20 22:56:46 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3F624 d:FF r:FFAE     m:0C A240 652E9A 424242 4525
2018.08.20 22:56:46 3: FS20 set Dimmer_11 timer 0
2018.08.20 22:56:47 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D3F789 d:FF r:FFAE     m:0D A240 652E9A 424242 4525
2018.08.20 22:56:47 3: FS20 set Dimmer_11 timer 0
2018.08.20 22:58:57 3: FS20 set Dimmer_11 off
2018.08.20 22:58:58 3: FS20 set Dimmer_11 on
2018.08.20 22:58:58 3: FS20 set Dimmer_11 off
2018.08.20 23:01:41 3: CUL_HM set HM_652E9A getConfig
2018.08.20 23:01:41 3: FS20 set Dimmer_11 on
2018.08.20 23:02:12 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D8EE04 d:FF r:FFC3     m:01 A640 652E9A 424242 0504
2018.08.20 23:02:12 0: HMLAN_Send:  hmusb S:S59252B37 stat:  00 t:00000000 d:01 r:59252B37 m:02 A001 424242 652E9A 00040000000000
2018.08.20 23:02:12 3: FS20 set Dimmer_11 off
2018.08.20 23:02:13 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D8F0DB d:FF r:FFC3     m:02 A010 652E9A 424242 0202010A420B420C4218000000
2018.08.20 23:02:13 0: HMLAN_Parse: hmusb R:R59252B37 stat:0001 t:16D8F0E0 d:FF r:FFC3     m:02 A010 652E9A 424242 0202010A420B420C4218000000
2018.08.20 23:02:13 0: HMLAN_Send:  hmusb S:S59252E94 stat:  00 t:00000000 d:01 r:59252E94 m:03 A001 424242 652E9A 01040000000001
2018.08.20 23:02:13 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D8F2E2 d:FF r:FFC2     m:03 A010 652E9A 424242 020410080009000000
2018.08.20 23:02:13 0: HMLAN_Parse: hmusb R:R59252E94 stat:0001 t:16D8F2E7 d:FF r:FFC2     m:03 A010 652E9A 424242 020410080009000000
2018.08.20 23:02:13 0: HMLAN_Send:  hmusb S:S59253096 stat:  00 t:00000000 d:01 r:59253096 m:04 A001 424242 652E9A 0103
2018.08.20 23:02:14 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D8F4EF d:FF r:FFC3     m:04 A010 652E9A 424242 0140BB460140BB9C0100000000
2018.08.20 23:02:14 0: HMLAN_Parse: hmusb R:R59253096 stat:0001 t:16D8F4F4 d:FF r:FFC3     m:04 A010 652E9A 424242 0140BB460140BB9C0100000000
2018.08.20 23:02:14 0: HMLAN_Send:  hmusb S:S59253296 stat:  00 t:00000000 d:01 r:59253296 m:05 A001 424242 652E9A 02040000000001
2018.08.20 23:02:14 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D8F6F6 d:FF r:FFC2     m:05 A010 652E9A 424242 020410080009000000
2018.08.20 23:02:14 0: HMLAN_Parse: hmusb R:R59253296 stat:0001 t:16D8F6FB d:FF r:FFC2     m:05 A010 652E9A 424242 020410080009000000
2018.08.20 23:02:14 0: HMLAN_Send:  hmusb S:S592534B6 stat:  00 t:00000000 d:01 r:592534B6 m:06 A001 424242 652E9A 0203
2018.08.20 23:02:15 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D8F8FD d:FF r:FFC2     m:06 A010 652E9A 424242 0100000000
2018.08.20 23:02:15 0: HMLAN_Parse: hmusb R:R592534B6 stat:0001 t:16D8F902 d:FF r:FFC2     m:06 A010 652E9A 424242 0100000000
2018.08.20 23:02:15 0: HMLAN_Send:  hmusb S:S592536B6 stat:  00 t:00000000 d:01 r:592536B6 m:07 A001 424242 652E9A 03040000000001
2018.08.20 23:02:15 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D8FB0A d:FF r:FFC1     m:07 A010 652E9A 424242 020410080009000000
2018.08.20 23:02:15 0: HMLAN_Parse: hmusb R:R592536B6 stat:0001 t:16D8FB0F d:FF r:FFC1     m:07 A010 652E9A 424242 020410080009000000
2018.08.20 23:02:15 0: HMLAN_Send:  hmusb S:S592538B6 stat:  00 t:00000000 d:01 r:592538B6 m:08 A001 424242 652E9A 0303
2018.08.20 23:02:16 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D8FD11 d:FF r:FFBF     m:08 A010 652E9A 424242 0100000000
2018.08.20 23:02:16 0: HMLAN_Parse: hmusb R:R592538B6 stat:0001 t:16D8FD16 d:FF r:FFBF     m:08 A010 652E9A 424242 0100000000
2018.08.20 23:02:16 0: HMLAN_Send:  hmusb S:S59253AD6 stat:  00 t:00000000 d:01 r:59253AD6 m:09 A001 424242 652E9A 04040000000001
2018.08.20 23:02:16 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D8FF1E d:FF r:FFBD     m:09 A010 652E9A 424242 020410080009000000
2018.08.20 23:02:16 0: HMLAN_Parse: hmusb R:R59253AD6 stat:0001 t:16D8FF23 d:FF r:FFBD     m:09 A010 652E9A 424242 020410080009000000
2018.08.20 23:02:16 0: HMLAN_Send:  hmusb S:S59253CD6 stat:  00 t:00000000 d:01 r:59253CD6 m:0A A001 424242 652E9A 0403
2018.08.20 23:02:17 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D90124 d:FF r:FFBB     m:0A A010 652E9A 424242 0100000000
2018.08.20 23:02:17 0: HMLAN_Parse: hmusb R:R59253CD6 stat:0001 t:16D90129 d:FF r:FFBB     m:0A A010 652E9A 424242 0100000000
2018.08.20 23:02:17 0: HMLAN_Send:  hmusb S:S59253ED6 stat:  00 t:00000000 d:01 r:59253ED6 m:0B A001 424242 652E9A 05040000000001
2018.08.20 23:02:17 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D90331 d:FF r:FFBA     m:0B A010 652E9A 424242 020410080009000000
2018.08.20 23:02:17 0: HMLAN_Parse: hmusb R:R59253ED6 stat:0001 t:16D90336 d:FF r:FFBA     m:0B A010 652E9A 424242 020410080009000000
2018.08.20 23:02:17 0: HMLAN_Send:  hmusb S:S592540D6 stat:  00 t:00000000 d:01 r:592540D6 m:0C A001 424242 652E9A 0503
2018.08.20 23:02:18 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D9053B d:FF r:FFBA     m:0C A010 652E9A 424242 014242423100000000
2018.08.20 23:02:18 0: HMLAN_Parse: hmusb R:R592540D6 stat:0001 t:16D90540 d:FF r:FFBA     m:0C A010 652E9A 424242 014242423100000000
2018.08.20 23:02:18 0: HMLAN_Send:  hmusb S:S592542F6 stat:  00 t:00000000 d:01 r:592542F6 m:0D A001 424242 652E9A 06040000000001
2018.08.20 23:02:18 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D90744 d:FF r:FFBB     m:0D A010 652E9A 424242 020410080009000000
2018.08.20 23:02:19 0: HMLAN_Parse: hmusb R:R592542F6 stat:0001 t:16D90749 d:FF r:FFBB     m:0D A010 652E9A 424242 020410080009000000
2018.08.20 23:02:19 0: HMLAN_Send:  hmusb S:S592544F6 stat:  00 t:00000000 d:01 r:592544F6 m:0E A001 424242 652E9A 0603
2018.08.20 23:02:19 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D9094B d:FF r:FFBB     m:0E A010 652E9A 424242 0100000000
2018.08.20 23:02:19 0: HMLAN_Parse: hmusb R:R592544F6 stat:0001 t:16D90950 d:FF r:FFBB     m:0E A010 652E9A 424242 0100000000
2018.08.20 23:02:19 0: HMLAN_Send:  hmusb S:S592546F6 stat:  00 t:00000000 d:01 r:592546F6 m:0F A001 424242 652E9A 010440BB460104
2018.08.20 23:02:19 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D90B55 d:FF r:FFBB     m:0F A010 652E9A 424242 0201000000
2018.08.20 23:02:20 0: HMLAN_Parse: hmusb R:R592546F6 stat:0001 t:16D90B5A d:FF r:FFBB     m:0F A010 652E9A 424242 0201000000
2018.08.20 23:02:20 0: HMLAN_Send:  hmusb S:S59254916 stat:  00 t:00000000 d:01 r:59254916 m:10 A001 424242 652E9A 010440BB9C0104
2018.08.20 23:02:20 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D90D5F d:FF r:FFBB     m:10 A010 652E9A 424242 0201000000
2018.08.20 23:02:20 0: HMLAN_Parse: hmusb R:R59254916 stat:0001 t:16D90D64 d:FF r:FFBB     m:10 A010 652E9A 424242 0201000000
2018.08.20 23:02:20 0: HMLAN_Send:  hmusb S:S59254B16 stat:  00 t:00000000 d:01 r:59254B16 m:11 A001 424242 652E9A 05044242423104
2018.08.20 23:02:21 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D90F69 d:FF r:FFBB     m:11 A010 652E9A 424242 0201000000
2018.08.20 23:02:21 0: HMLAN_Parse: hmusb R:R59254B16 stat:0001 t:16D90F6E d:FF r:FFBB     m:11 A010 652E9A 424242 0201000000
2018.08.20 23:02:31 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D93783 d:FF r:FFBA     m:02 A640 652E9A 424242 0505
2018.08.20 23:02:31 3: FS20 set Dimmer_11 on
2018.08.20 23:02:31 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D938E7 d:FF r:FFB9     m:03 A240 652E9A 424242 0505
2018.08.20 23:02:31 3: FS20 set Dimmer_11 off
2018.08.20 23:02:31 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D93A4C d:FF r:FFBA     m:04 A240 652E9A 424242 0505
2018.08.20 23:02:32 3: FS20 set Dimmer_11 on
2018.08.20 23:02:36 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D94C51 d:FF r:FFC6     m:05 A640 652E9A 424242 0506
2018.08.20 23:02:36 3: FS20 set Dimmer_11 off
2018.08.20 23:02:39 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D95891 d:FF r:FFC5     m:06 A640 652E9A 424242 0507
2018.08.20 23:02:39 3: FS20 set Dimmer_11 on
2018.08.20 23:02:40 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D959F6 d:FF r:FFC4     m:07 A240 652E9A 424242 0507
2018.08.20 23:02:40 3: FS20 set Dimmer_11 off
2018.08.20 23:02:40 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D95B5A d:FF r:FFC4     m:08 A240 652E9A 424242 0507
2018.08.20 23:02:40 3: FS20 set Dimmer_11 on
2018.08.20 23:02:45 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D96FA6 d:FF r:FFC7     m:09 A640 652E9A 424242 0508
2018.08.20 23:02:45 3: FS20 set Dimmer_11 off
2018.08.20 23:02:45 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D9710A d:FF r:FFC7     m:0A A240 652E9A 424242 0508
2018.08.20 23:02:46 3: FS20 set Dimmer_11 on
2018.08.20 23:02:46 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D9726F d:FF r:FFC7     m:0B A240 652E9A 424242 0508
2018.08.20 23:02:46 3: FS20 set Dimmer_11 off
2018.08.20 23:02:52 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D98A8B d:FF r:FFB2     m:0C A640 652E9A 424242 0509
2018.08.20 23:02:52 3: FS20 set Dimmer_11 on
2018.08.20 23:02:52 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D98BF0 d:FF r:FFB4     m:0D A240 652E9A 424242 0509
2018.08.20 23:02:52 3: FS20 set Dimmer_11 off
2018.08.20 23:02:53 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D98D54 d:FF r:FFB4     m:0E A240 652E9A 424242 0509
2018.08.20 23:02:53 3: FS20 set Dimmer_11 on
2018.08.20 23:03:02 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D9B358 d:FF r:FFC5     m:0F A640 652E9A 424242 050A
2018.08.20 23:03:03 3: FS20 set Dimmer_11 off
2018.08.20 23:03:06 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D9C164 d:FF r:FFC6     m:10 A640 652E9A 424242 050B
2018.08.20 23:03:06 3: FS20 set Dimmer_11 on
2018.08.20 23:03:09 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D9CCBD d:FF r:FFC5     m:11 A640 652E9A 424242 050C
2018.08.20 23:03:09 3: FS20 set Dimmer_11 off
2018.08.20 23:03:12 0: HMLAN_Parse: hmusb R:E652E9A   stat:0000 t:16D9D854 d:FF r:FFC6     m:12 A640 652E9A 424242 050D

List Channel:

Code Auswählen Erweitern


Internals:
   DEF        652E9A05
   IODev     
   NAME       HM_Switch_Btn_11
   NOTIFYDEV  global
   NR         1354
   STATE      Short 1_13 (to vccu)
   TYPE       CUL_HM
   chanNo     05
   device     HM_652E9A
   peerList   vccu_Btn49,
   protState  Info_Cleared
   READINGS:
     2018-08-11 07:30:54   R-sign          off
     2018-08-18 10:51:45   R-vccu_Btn49-expectAES off
     2018-08-18 10:51:45   R-vccu_Btn49-peerNeedsBurst off
     2018-08-20 23:02:17   RegL_01.          04:10 08:00 09:00 00:00
     2018-08-20 23:02:21   RegL_04.vccu_Btn49   01:00 00:00
     2018-08-20 23:02:18   peerList        vccu_Btn49,
     2018-08-20 23:03:12   state           Short 1_13 (to vccu)
     2018-08-20 23:03:12   trigger         Short_13
     2018-08-20 23:03:12   trigger_cnt     13
   helper:
     BNO        13
     BNOCNT     1
     peerIDsRaw ,42424231,00000000
     regLst     ,1,4p
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     prt:
       bErr       0
       sProc      0
     role:
       chn        1
     shadowReg:
     tmpl:
Attributes:
   alias      6fachSchalterBad05
   model      HM-PB-6-WM55
   peerIDs    00000000,42424231,
   room       Bad
   

list Device

Code Auswählen Erweitern

Internals:
   DEF        652E9A
   IODev      hmusb
   LASTInputDev hmusb
   MSGCNT     554
   NAME       HM_652E9A
   NOTIFYDEV  global
   NR         1348
   STATE      HM_Switch_Btn_11 Short
   TYPE       CUL_HM
   channel_01 HM_652E9A_Btn_01
   channel_02 HM_652E9A_Btn_02
   channel_03 HM_652E9A_Btn_03
   channel_04 HM_652E9A_Btn_04
   channel_05 HM_Switch_Btn_11
   channel_06 HM_652E9A_Btn_06
   hmusb_MSGCNT 554
   hmusb_RAWMSG E652E9A,0000,16D9D854,FF,FFC6,12A640652E9A424242050D
   hmusb_RSSI -58
   hmusb_TIME 2018-08-20 23:03:12
   lastMsg    No:12 - t:40 s:652E9A d:424242 050D
   protLastRcv 2018-08-20 23:03:12
   protRcv    525 last_at:2018-08-20 23:03:12
   protResnd  1 last_at:2018-08-20 23:01:46
   protSnd    384 last_at:2018-08-20 23:03:12
   protState  CMDs_done
   rssi_at_hmusb cnt:554 min:-91 max:-39 avg:-73.15 lst:-58
   READINGS:
     2018-08-18 10:54:32   CommandAccepted yes
     2018-08-07 18:59:01   D-firmware      1.2
     2018-08-07 18:59:01   D-serialNr      OEQ2114781
     2018-08-20 23:02:13   PairedTo        0x424242
     2018-08-07 19:07:54   R-pairCentral   0x424242
     2018-08-20 23:02:13   RegL_00.          02:01 0A:42 0B:42 0C:42 18:00 00:00
     2018-08-20 23:00:09   alive           yes
     2018-08-20 23:03:12   battery         ok
     2018-08-20 23:00:09   powerOn         2018-08-20 23:00:09
     2018-08-20 23:00:09   recentStateType info
     2018-08-20 23:03:12   state           HM_Switch_Btn_11 Short
   helper:
     HM_CMDNR   18
     PONtest    1
     cSnd       01424242652E9A010440BB9C0104,01424242652E9A05044242423104
     mId        00A9
     regLst     ,0
     rxType     28
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newCh      1
       newChn     +652E9A,00,01,00
       nextSend   1534798992.50313
       prefIO     
       rxt        2
       vccu       vccu
       p:
         652E9A
         00
         01
         00
     mRssi:
       mNo        12
       io:
         hmusb:
           -52
           -52
     prt:
       bErr       0
       sProc      0
       sleeping   0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
     rpt:
       IO         hmusb
       flg        A
       ts         1534798992.43071
       ack:
         HASH(0x39a5860)
         128002424242652E9A00
     rssi:
       at_hmusb:
         avg        -73.1552346570398
         cnt        554
         lst        -58
         max        -39
         min        -91
     shadowReg:
     tmpl:
Attributes:
   IODev      hmusb
   IOgrp      vccu
   alias      6fachSchalterBad
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.2
   model      HM-PB-6-WM55
   room       Bad
   serialNr   OEQ2114781
   subType    remote
   webCmd     getConfig:clear msgEvents
   

list vccu Button:

Code Auswählen Erweitern


+

Internals:
   DEF        42424231
   NAME       vccu_Btn49
   NOTIFYDEV  global
   NR         103
   STATE      ???
   TYPE       CUL_HM
   chanNo     31
   device     vccu
   peerList   HM_Switch_Btn_11,
   READINGS:
     2018-08-18 10:54:23   peerList        HM_Switch_Btn_11,
     2018-08-20 23:03:12   trigLast        HM_Switch_Btn_11:short
     2018-08-20 23:03:12   trig_HM_Switch_Btn_11 Short_13
   helper:
     regLst     
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     role:
       chn        1
       vrt        1
Attributes:
   model      CCU-FHEM
   peerIDs    652E9A05,
   webCmd     press short:press long
   

Grüße
Martin

[dadoc]

Guten Morgen,
das Problem hält an, anscheinend hatten andere ähnliche Probleme, wobei ich bei keinem Fall eine wirklich Lösung fand:
https://forum.fhem.de/index.php/topic,10436.0.html

https://forum.fhem.de/index.php/topic,19714.0.html

https://forum.fhem.de/index.php?topic=41834.0

https://forum.fhem.de/index.php?topic=26134.0

Es hat (bei mir) BTW auch nichts mit dem ACK/Bestätigung durch grüne LED zu tun. Auch wenn grün bestätigt wird, sendet die Taste gelegentlich doppelt oder dreifach.

@Otto: Danke für den Hinweis mit dem RSSI-Loggen. Der hat mich darauf gebracht, dass das durch Setzen des attr rssiLog ja noch aussagekräftiger wird:
Ich bin zwar kein Experte, aber ich denke, es hat nichts mit dem rssi zu tun?

Beispiel für eine Mehrfachschaltung aus dem Log des Device:

Code Auswählen Erweitern


2018-08-25_12:06:36 HM_652E9A battery: ok
2018-08-25_12:06:36 HM_652E9A rssi_at_hmusb: -74
2018-08-25_12:06:36 HM_652E9A CMDs_done
2018-08-25_12:06:36 HM_652E9A HM_Switch_Btn_11 Short
2018-08-25_12:06:37 HM_652E9A battery: ok
2018-08-25_12:06:37 HM_652E9A rssi_at_hmusb: -76
2018-08-25_12:06:37 HM_652E9A CMDs_done
2018-08-25_12:06:37 HM_652E9A HM_Switch_Btn_11 Short
2018-08-25_12:06:37 HM_652E9A battery: ok
2018-08-25_12:06:37 HM_652E9A rssi_at_hmusb: -79
2018-08-25_12:06:37 HM_652E9A CMDs_done
2018-08-25_12:06:37 HM_652E9A HM_Switch_Btn_11 Short


ditto aus dem Event Monitor:

Code Auswählen Erweitern

2018-08-25 12:06:36 CUL_HM HM_Switch_Btn_11 Short 1_94 (to vccu)
2018-08-25 12:06:36 CUL_HM HM_Switch_Btn_11 trigger: Short_94
2018-08-25 12:06:36 CUL_HM HM_Switch_Btn_11 trigger_cnt: 94
2018-08-25 12:06:36 CUL_HM vccu_Btn49 trigLast: HM_Switch_Btn_11:short
2018-08-25 12:06:36 CUL_HM vccu_Btn49 trig_HM_Switch_Btn_11: Short_94
2018-08-25 12:06:37 CUL_HM HM_652E9A HM_Switch_Btn_11 Short
2018-08-25 12:06:37 CUL_HM HM_Switch_Btn_11 Short 2_94 (to vccu)
2018-08-25 12:06:37 CUL_HM HM_Switch_Btn_11 trigger: Short_94
2018-08-25 12:06:37 CUL_HM HM_Switch_Btn_11 trigger_cnt: 94
2018-08-25 12:06:37 CUL_HM vccu_Btn49 trigLast: HM_Switch_Btn_11:short
2018-08-25 12:06:37 CUL_HM vccu_Btn49 trig_HM_Switch_Btn_11: Short_94
2018-08-25 12:06:37 CUL_HM HM_652E9A HM_Switch_Btn_11 Short
2018-08-25 12:06:37 CUL_HM HM_Switch_Btn_11 Short 3_94 (to vccu)
2018-08-25 12:06:37 CUL_HM HM_Switch_Btn_11 trigger: Short_94
2018-08-25 12:06:37 CUL_HM HM_Switch_Btn_11 trigger_cnt: 94
2018-08-25 12:06:37 CUL_HM vccu_Btn49 trigLast: HM_Switch_Btn_11:short
2018-08-25 12:06:37 CUL_HM vccu_Btn49 trig_HM_Switch_Btn_11: Short_94
Habt Ihr noch Tipps für mich?
Danke & Grüße
Martin

[Otto123]

Hallo Martin,

das er das jedes mal mit sendet: 2018-08-25_12:06:37 HM_652E9A CMDs_done

Ist nicht normal.

Ich bin der Meinung er wiederholt. Wenn ich dreimal drücke sieht es verkürzt so aus:

Code Auswählen Erweitern

2018-08-25 12:31:14.232 CUL_HM FB12_Btn_01 Short 1_129 (to broadcast)
2018-08-25 12:31:39.983 CUL_HM FB12_Btn_01 Short 1_130 (to broadcast)
018-08-25 12:31:46.369 CUL_HM FB12_Btn_01 Short 1_131 (to broadcast)
Bei Dir

Code Auswählen Erweitern

2018-08-25 12:06:36 CUL_HM HM_Switch_Btn_11 Short 1_94 (to vccu)
2018-08-25 12:06:37 CUL_HM HM_Switch_Btn_11 Short 2_94 (to vccu)
2018-08-25 12:06:37 CUL_HM HM_Switch_Btn_11 Short 3_94 (to vccu)

Bei mir gibt es keine Erhöhung der Zahl vor dem "_" bei Dir gibt es keine Erhöhung hinter dem "_"

Er wiederholt dreimal weil er keine Bestätigung bekommt - vermute ich.

Gruß Otto

[dadoc]

Hallo Otto,

Wenn ich dreimal drücke sieht es verkürzt so aus:

Das Problem ist: Ich drücke ja nicht dreimal, sondern nur einmal, und wie beschrieben, das tritt ja auch dann auf, wenn der Tastendruck bestätigt wird (LED grün).
Was könnte ich noch tun, um dem Problem auf den Grund zu kommen?
Grüße
Martin

[Otto123]

Ich wollte Dir ja damit bestätigen, dass Du nur einmal drückst. Und auch der Taster an sich nicht mehrfach betätigt wird obwohl Du nur einmal drückst. Sein Peer sendet offenbar kein Ack, bzw. erst beim dritten mal.

Gruß Otto

[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


[Otto123]

Hallo Martin,
Ehrlich: Ich weiß nicht was Du gemacht hast 
Ich wollte schon gern auf dem aufbauen was Du mal gezeigt, ich mach mir schon Gedanken, dass nichts kaputt geht und nachvollziehbare Ergebnisse kommen könnten. Aber Du machst was völlig anderes. Mag sein das es nicht falsch ist, aber für mich ist das alles nicht nachvollziehbar 
Irgendwelche toggel Schaltungen vollführen, mag zwar optisch für Dich erbaulich sein, aber helfen tun sie gar nicht.

Der einzige verständliche Post war die Nummer #26 darauf bauten meine Empfehlungen auf. Dann könnte man nämlich mit Wiederholung dieser Eventfolge und des Logs sehen ob mein Ansatz der richtige wäre.
Die Idee den Funk generell zu entzerren ist gut und richtig, aber beim nächsten Störer läuft dein Trigger wieder mehrfach.

Abschließend bin ich der Meinung, meine Empfehlung aus #34 ist der richtige Ansatz, bei wiederholtem, gleichem Short Event nur einmal zu triggern.
Das regExp kann man noch verfeinern, da Du mehrere Schalter damit bearbeiten willst.

Gruß Otto

[dadoc]

Hallo Otto,

Ehrlich: Ich weiß nicht was Du gemacht hast 

Sorry, wenn ich für Verwirrung sorge. Ich dachte eigentlich, ich hätte ziemlich genau das gemacht, was Du vorgeschlagen hattest, das war in Post #40:

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"}
Das habe ich umgesetzt als

Code Auswählen Erweitern

HM_653129:HM_Switch_Btn_...Short  {Log 1, fhem "set Dimmer_02 toggle"}
d.h. für Dein "Hier steht hoffentlich pro Tastendruck nur ein Eintrag" habe ich zum Testen  fhem "set Dimmer_02 toggle" genommen (weil es mit Deinem notify, ohne den on/off-Wechsel aus meinem notifys, schwierig zu Testen war. Daher verstehe ich nicht ganz, was das Problem mit toggle ist - damit sieht man im Log doch sehr schön die Mehrfachsendungen pro Tastendruck?

Abschließend bin ich der Meinung, meine Empfehlung aus #34 ist der richtige Ansatz, bei wiederholtem, gleichem Short Event nur einmal zu triggern.
Das regExp kann man noch verfeinern, da Du mehrere Schalter damit bearbeiten willst.

Nur bleibt das in der Praxis ja wirkungslos, es wird weiterhin 1-, 2- oder 3-mal gesendet, außer ich stelle mich maximal 2 Meter vor den hmusb.
So habe ich das auch im Logauszug in #41 geposted.
Viele Grüße
Martin

[Otto123]

Nein hast Du nicht. Du hast andere Schalter genommen, attribute nicht gesetzt und nicht den Eventmonitor wie in #26 mit vergleichbaren Informationen aus dem Log in Übereinstimmung gebracht.
Es bleibt aus meiner Sicht nicht wirkungslos, weil dieser Event

Code Auswählen Erweitern

2018-08-25 12:06:37 CUL_HM HM_652E9A HM_Switch_Btn_11 Short
durch diese Attribute

Code Auswählen Erweitern

attr HM_652E9A event-on-change-reading stateNicht dreimal auftaucht sondern nur einmal.

Kann sein, dass dann dort nie wieder ein Event auftaucht, weil sich der state bei wiederholtem echten drücken nicht mehr ändert.
Dann geht zumindest die Kombination

Code Auswählen Erweitern

2018-08-25 12:06:36 CUL_HM HM_Switch_Btn_11 trigger: Short_94
attr HM_Switch_Btn_11 event-on-change-reading trigger

Du brauchst bloß mal beide Attribute setzen und den Versuch aus #26 wiederholen. Aber eben mit dem gleichen Schalter 

Aber mag auch sein ich  liege daneben 

Gruß Otto

[dadoc]

Danke Otto,

Nein hast Du nicht. Du hast andere Schalter genommen,

Wie beschrieben, ist der HM_653129 ein absolut identischer Schalter zum HM_652E9A - beide nagelneu und zusammen gekauft. Ich wollte nur ausschließen, dass der erste Schalter einen Defekt im Funkmodul hatte (hatte ich auch schon einmal). Aber das attr hatte ich verbaselt, das stimmt.

Code Auswählen Erweitern

Nicht dreimal auftaucht sondern nur einmal.
Ich werde das heute Abend noch einmal ganz systematisch ausprobieren.
Danke & Grüße
Martin

[frank]

ich würde bei homematic nie auf state triggern, wenn es andere readings gibt.

wenn zb nach jedem "short" "cmds_done" kommen würde, bringt zb events-on-change gar nichts.

mein hinweis auf das trigger reading war kein "ausrutscher".

[dadoc]

Hallo Frank,

mein hinweis auf das trigger reading war kein "ausrutscher".

Ich stehe da etwas auf der Leitung - meinst Du damit, dass das notify auslösen sollte auf (z.B.) "trigger: "?
Grüße
Martin

[frank]

Code Auswählen Erweitern

2018-08-25 12:06:36 CUL_HM HM_Switch_Btn_11 trigger: Short_94
so sieht dein trigger event für short aus.

dann würde ich folgende regex für ein notify nehmen, um bei jedem short event zu triggern:

Code Auswählen Erweitern

HM_Switch_Btn_11.trigger:.Short_.*

[dadoc]

Vielen Dank, werde ich heute Abend ebenfalls testen. Habe halt nur die Sorge, dass das auch so und trotz events-on-change mehrfach nach einem Tastendruck auftaucht...

[frank]

Code Auswählen Erweitern

2018-08-18 09:14:44 CUL_HM HM_652E9A HM_Switch_Btn_11 Short
2018-08-18 09:14:44 CUL_HM HM_Switch_Btn_11 Short 1_201 (to vccu)
2018-08-18 09:14:44 CUL_HM HM_Switch_Btn_11 trigger: Short_201
2018-08-18 09:14:45 CUL_HM HM_652E9A HM_Switch_Btn_11 Short
2018-08-18 09:14:45 CUL_HM HM_Switch_Btn_11 Short 2_201 (to vccu)
2018-08-18 09:14:45 CUL_HM HM_Switch_Btn_11 trigger: Short_201
2018-08-18 09:14:45 CUL_HM HM_652E9A HM_Switch_Btn_11 Short
2018-08-18 09:14:45 CUL_HM HM_Switch_Btn_11 Short 3_201 (to vccu)
2018-08-18 09:14:45 CUL_HM HM_Switch_Btn_11 trigger: Short_201
diese events hast du gepostet für ein short ereignis, dass 2x wiederholt wurde. im trigger reading wird dafür 3x Short_11 ausgelöst. mit event-on-change würden die 2 wiederholungen weggefiltert. da jedes "echte" neue short eine andere ereigniszahl liefert, kommen diese neuen shorts auch durch und können toggeln.

eigentlich doch logisch, oder?

[Otto123]

ich würde bei homematic nie auf state triggern, wenn es andere readings gibt.

wenn zb nach jedem "short" "cmds_done" kommen würde, bringt zb events-on-change gar nichts.

mein hinweis auf das trigger reading war kein "ausrutscher".

Da hast Du absolut Recht, hab ich nicht dran gedacht. Aber ich hatte ja beide Varianten konkret vorgeschlagen 
Dein Hinweis mit trigger war zu wenig dominant  das "nie auf state" muss ich mir einbrennen.

Gruß Otto

[dadoc]

eigentlich doch logisch, oder?

Ja, jetzt hats Klick gemacht. Danke.

[dadoc]

Guten Morgen,
sowohl mit

Code Auswählen Erweitern

sleep 1
also auch mit

Code Auswählen Erweitern

=~ "trigger: Short_"
in Verbindung mit

Code Auswählen Erweitern

event-on-change-reading trigger
hat das Mehrfachsenden ein Ende - nochmals vielen Dank für all die Tipps.
Bei Letzterem ergibt sich jetzt noch das Problem, dass das LongRelease, das ich im notify zum Stoppen der Dimmerrampe nutze, nicht wie "trigger" ein Reading ist, sondern direkt in state bzw. STATE zu landen scheint.
Erste Versuche mit

Code Auswählen Erweitern

event-on-change-reading trigger,STATE=~LongRelease

waren bislang noch nicht erfolgreich.
Muss man bei der Regex für event-on-change-reading etwas Besonderes beachten? Habe nichts dazu gefunden.
Grüße
Martin

[frank]

ich setze grundsätzlich bei allen fhem devices, also auch bei den homematic-channel-devices

Code Auswählen Erweitern

attr <device> event-on-change-reading .*
damit kann man erst eimal, ohne gross nachzudenken, die eventflut für alle readings auf das nötigste reduzieren.
stellt man später fest, dass man für spezielle readings mehr events benötigt, kann man für diese readings dann zusätzlich event-on-update und/oder event-min-interval setzen.

vor allem kann es so nicht vorkommen, dass man events für manche readings komplett abschaltet. denn für alle readings, die bei event-on-change nicht genannt werden, gibt es gar keine readings mehr.

setze also mal event-on-change entsprechend und zeige die events vom eventmonitor für ein long ereignis.

[dadoc]

Vielen Dank Frank,
damit ich das hier nicht zu weit ins OT treibe (ungewollte Mehrfachsendungen würde ich dank Eurer Hilfe als gelöst betrachten), verlege ich mich mal auf den ursprünglichen Thread, der das Problem mit den Mehrfachsendung erst aufwarf. Da hatte ich in #5 mal die Events für zwei Longpress geposted. Wenn ich heute Abend wieder vor Ort bin, kann ich noch mehr liefern...
Viele Grüße
Martin

[Otto123]

Hallo Martin,

ich mache es wie Frank mit .*

Mit deinem Experiment

Code Auswählen Erweitern

event-on-change-reading trigger,STATE=~LongReleasemusst Du sehr vorsichtig sein.. Da geht schnell gar nichts mehr Event Technisch
Bitte unbedingt die Doku beachten und keinen Wunschlesemodus aktiv schalten - im Zweifelsfall testen testen testen.

Für meine Begriffe geht es im regExp nur darum den Reading Namen zu filtern und nicht den Event. Aber ich kann falsch liegen.

event-on-change-reading
The attribute takes a comma-separated list of readings. You may use regular expressions in that list. If set, only changes of the listed readings create events. In other words, if a reading listed here is updated with the new value identical to the old value, no event is created. If an optional [:threshold] is given after a reading name events are only generated if the change is >= threshold.
The precedence of event-on-update-reading and event-on-change-reading is as follows:
If both attributes are not set, any update of any reading of the device creates an event.
If any of the attributes is set, no events occur for updates or changes of readings not listed in any of the attributes.
If a reading is listed in event-on-update-reading, an update of the reading creates an event no matter whether the reading is also listed in event-on-change-reading.

Gruß Otto

[dadoc]

ich mache es wie Frank mit .*

Ah ok, ich dachte, ich müsste unbedingt auch

Code Auswählen Erweitern

event-on-change-reading trigger
setzen, damit sich die Events nicht wiederholen. Wenn es auch .* sein kann, dürfte das mit den LongReleases kein Problem sein, das hat ja vorher auch funktioniert. Werde ich testen.

Code Auswählen Erweitern

Für meine Begriffe geht es im regExp nur darum den Reading Namen zu filtern und nicht den Event. Aber ich kann falsch liegen.
Wie gesagt: Im Gegensatz zu Long und Short landet LongRelease offensichtlich nicht in einem Reading bzw. direkt in state und STATE.

Grüße
Martin

[Otto123]

Doch auch state ist ein Reading   
state = Reading
STATE = Internal

[dadoc]

Hallo Otto,
schon klar, dass state bei den Readings auftaucht, aber ich dachte...:

ich würde bei homematic nie auf state triggern, wenn es andere readings gibt.

Nun, in diesem Fall gibt es keine anderen für LongRelease.
Freue mich schon auf's Testen heute Abend

[frank]

ausserdem gibt es kein reading STATE.

[dadoc]

Wollte ich auch nie behauptet haben... nur state

[dadoc]

Alles bestens jetzt, habe doch noch einen Event gefunden, der den Beginn eines langen Tastendrucks kennzeichnet. So konnte ich das Notify stark vereinfachen. In der vorläufigen Endfassung und mit Kommentaren findet es sich hier.
Nochmals Danke für Eure Hilfe &
Viele Grüße
Martin