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​