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:
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:
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:
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:
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
Ich sehe das eventonchangereading .* nicht. Das sollte man überall - zumindest in culhm vorsehen.
Ist so auch im Wiki empfohlen
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 ... ?
In Ergänzung: Schau Dir den Eventmonitor an, der erklärt meistens sehr bildlich das Problem mit mehrfach Events und Auslösung.
Gruß Otto
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:
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):
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
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.
ZitatAnscheinend 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.
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.
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.
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 :D.
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):
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:
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):
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):
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
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
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
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
Zitat von: Otto123 am 27 November 2017, 13:57:56
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.
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.
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
Zitat von: martinp876 am 27 November 2017, 21:05:06
wird eine Wiederholung an den Magnumkern erkannt.
Da hat die Autokorrektur aber diesmal so zugeschlagen, dass ich den Sinn nicht mehr erkennen kann. "Aktoren"?
ZitatDas 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.
Hallo Gisbert,
bei grüner Quittung hast Du alles richtig gemacht! ;D
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)
ZitatExample:
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
Hallo zusammen,
Ich hänge mich mal der Auffindbarkeit halber an diesen älteren Thread, weil ich genau (?) dasselbe Phänomen beobachte.
Zitat von: Pfriemler am 27 November 2017, 20:45:37
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):
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
rssi_at_hmusb cnt:415 min:-91 max:-39 avg:-73.02 lst:-70Aber selbst wenn nicht, verstehe ich Eure Antworten (s.o.) so, dass fhem dann nicht einfach mehrmals pro Sekunde senden sollte.
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
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.
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
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.
sniffen, wie im wiki beschrieben.
poste je ein list vom device, channel und vccu-channel.
ein eigener thread wäre sicher sinnvoller gewesen.
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:
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
Zitat von: frank am 18 August 2018, 20:35:15
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.
Zitat
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.
Guten Morgen,
Sniffed (mal weiter (rot), mal näher (grün) am CUL):
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:
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
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:
+
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
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:
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:
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
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:
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
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
Hallo Otto,
Zitat von: Otto123 am 25 August 2018, 12:35:54
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
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
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.
Zu Franks Idee:
Du hast sogar zwei Events auf die Du triggern kannst
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
dazuattr HM_Switch_Btn_11 event-on-change-reading trigger
attr HM_652E9A event-on-change-reading state
Gruß Otto
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: 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
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
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:
HM_652E9A:HM_Switch_Btn_...Short und dies setzen
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
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:
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.
Für mich liegt der Hase begraben in (aus dem notify-Eintrag im Wiki):
ZitatDas 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
elsif ($Press_Event ~= " Short")was für mich übersetzt "ein Event, der Leerzeichen, gefolgt von Short, gefolgt von Zeilenende" bedeutet, geändert in
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?
Zitat von: dadoc am 26 August 2018, 17:57:03
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 :D
Also mach doch bitte mal
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
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.
Hallo Otto,
Zitat von: Otto123 am 26 August 2018, 19:54:19
Also mach doch bitte mal
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.
ZitatDann 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.
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...
Hallo Otto,
Dein Test-Notify in dieser Form
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:
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...
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)?
Machst Du mal bitte ein list HM_652E9A
Sicher hast Du dies vergessen: attr HM_652E9A event-on-change-reading state
Zitat von: Otto123 am 28 August 2018, 08:41:02
Machst Du mal bitte ein list HM_652E9A
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)
Zitat
Sicher hast Du dies vergessen: 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
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:
Zitat von: Pfriemler am 28 August 2018, 08:19:39
Hast du mal testweise versucht, die Befehle an den Dimmer zu verzögern (sleep 1 sollte reichen)?
Mit
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:
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
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
Hallo Otto,
Zitat von: Otto123 am 28 August 2018, 10:44:10
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:
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
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?
ZitatAbschließ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
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
2018-08-25 12:06:37 CUL_HM HM_652E9A HM_Switch_Btn_11 Short
durch diese Attribute
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
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 :o
Aber mag auch sein ich liege daneben ???
Gruß Otto
Danke Otto,
Zitat von: Otto123 am 28 August 2018, 11:26:22
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.
Nicht dreimal auftaucht sondern nur einmal.Ich werde das heute Abend noch einmal ganz systematisch ausprobieren.
Danke & Grüße
Martin
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".
Hallo Frank,
Zitat von: frank am 28 August 2018, 11:51:53
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
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:
HM_Switch_Btn_11.trigger:.Short_.*
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...
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?
Zitat von: frank am 28 August 2018, 11:51:53
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
Zitat von: frank am 28 August 2018, 14:05:24
eigentlich doch logisch, oder?
Ja, jetzt hats Klick gemacht. Danke.
Guten Morgen,
sowohl mit
sleep 1
also auch mit
=~ "trigger: Short_"
in Verbindung mit
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
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
ich setze grundsätzlich bei allen fhem devices, also auch bei den homematic-channel-devices
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.
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 (https://forum.fhem.de/index.php/topic,90178.msg826892.html#msg826892) 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
Hallo Martin,
ich mache es wie Frank mit .*
Mit deinem Experiment
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. ;D
Für meine Begriffe geht es im regExp nur darum den Reading Namen zu filtern und nicht den Event. Aber ich kann falsch liegen.
Zitatevent-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
Zitat von: Otto123 am 29 August 2018, 12:45:32
ich mache es wie Frank mit .*
Ah ok, ich dachte, ich müsste unbedingt auch
event-on-change-reading triggersetzen, 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.
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
Doch auch state ist ein Reading :D
state = Reading
STATE = Internal
Hallo Otto,
schon klar, dass state bei den Readings auftaucht, aber ich dachte...:
Zitat von: frank am 28 August 2018, 11:51:53
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 ;)
ausserdem gibt es kein reading STATE.
Wollte ich auch nie behauptet haben... nur state
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 (https://forum.fhem.de/index.php/topic,90178.msg831634.html#msg831634).
Nochmals Danke für Eure Hilfe &
Viele Grüße
Martin