Hallo,
ich habe einige der neuen 4-Tasten-Sender (HM-RC-SEC3-B) im Einsatz
Leider schicken die Sender bei einem Tastendruck die Nachrichten manchmal 2- oder 3-fach.
Im Log sieht das dann so aus:
2014-02-02_21:14:34 HS_Alarm_5 battery: ok
2014-02-02_21:14:34 HS_Alarm_5 HS_Alarm_5_Btn_04 Short (to HMLAN1)
2014-02-02_21:14:34 HS_Alarm_5_Btn_04 Short (to HMLAN1)
2014-02-02_21:14:34 HS_Alarm_5_Btn_04 trigger: Short_58
2014-02-02_21:14:34 HS_Alarm_5 battery: ok
2014-02-02_21:14:34 HS_Alarm_5 HS_Alarm_5_Btn_04 Short (to HMLAN1)
2014-02-02_21:14:34 HS_Alarm_5_Btn_04 Short (to HMLAN1)
2014-02-02_21:14:34 HS_Alarm_5_Btn_04 trigger: Short_58
2014-02-02_21:14:34 HS_Alarm_5 battery: ok
2014-02-02_21:14:34 HS_Alarm_5 HS_Alarm_5_Btn_04 Short (to HMLAN1)
2014-02-02_21:14:34 HS_Alarm_5_Btn_04 Short (to HMLAN1)
2014-02-02_21:14:34 HS_Alarm_5_Btn_04 trigger: Short_58
Ist halt blöd wenn man z.B. das Licht via "notify" und "toggle" ansteuern will - dann hat man DISCO.
Hat Jemand einen Tip ffür mich wie ich das in meinem Notify abfangen kann.
der Notify sieht z.Zt so aus:
define not_HS_Alarm_Btn_04 notify HS_Alarm_.*Btn_04:trigger.* set SW_Aussenlicht toggle
Du hast vermutlich ein Timing-Problem, sodass die erwartete Rückmeldung innerhalb einer vorgegebenen Zeit beim Sender ankommt. Deshalb wird die Nachricht wiederholt. Standardmäßig gibt es m.W. drei Wiederholungen. Mit dem Attribut msgRepeat kannst Du den Wert ändern.
ABER: Du soltest herausfinden, warum die Antwort nicht ankommt, denn wenn Du das msgRepeat runtersetzt, wird dein Handsender vermutlich mit einer roten Fehlermeldung reagieren.
achja - und eigentlich gibts für Homematic-Fragen ein eigenes Unterforum ;)
Short_58
der nächste sollte
Short_59
sein - prüfe auf Änderung. 2 Gleiche sind nicht Gültig.
Und prüfe, warum wiederholt wird. - Level probleme (RSSI)? oder kommt das ack nicht? - rohmessages schiken, mt virtuel actor peeren (der prüft übrigens auf wiederholer;))
Hallo Martin
ich habe mal ein log mitgeschrieben.
Das Phenomen lässt sich eher provozieren wenn man dem FHEM (und dem HMLAN) was zu tun gibt.
Vielleicht (wieder) ein Problem mit dem HMLAN
Gut-Fall:
2014.02.04 20:34:16.530 0: HMLAN_Parse: HMLAN1 R:E239D9F stat:0000 t:00072E98 d:FF r:FFB2 m:52 A240 239D9F 706958 0323
2014.02.04 20:34:16.625 0: HMLAN_Send: HMLAN1 S:SFE64D21E stat: 00 t:00000000 d:01 r:FE64D21E m:52 8002 706958 239D9F 0101C800
2014.02.04 20:34:16.916 0: HMLAN_Parse: HMLAN1 R:RFE64D21E stat:0002 t:00000000 d:FF r:7FFF m:52 8002 706958 239D9F 0101C800
Schlecht-Fall (Nachricht wurde 2x gesendet)
2014.02.04 20:42:13.369 0: HMLAN_Parse: HMLAN1 R:E239D9F stat:0000 t:00057849 d:FF r:FFA8 m:BD A240 239D9F 706958 037E
2014.02.04 20:42:13.465 0: HMLAN_Send: HMLAN1 S:SFE6C18CF stat: 00 t:00000000 d:01 r:FE6C18CF m:BD 8002 706958 239D9F 0101C800
2014.02.04 20:42:13.714 0: HMLAN_Parse: HMLAN1 R:E239D9F stat:0000 t:00057943 d:FF r:FFA9 m:BE A240 239D9F 706958 037E
2014.02.04 20:42:13.724 0: HMLAN_Send: HMLAN1 S:SFE6C1A1F stat: 00 t:00000000 d:01 r:FE6C1A1F m:BE 8002 706958 239D9F 0101C800
2014.02.04 20:42:14.247 0: HMLAN_Parse: HMLAN1 R:RFE6C18CF stat:0002 t:00000000 d:FF r:7FFF m:BD 8002 706958 239D9F 0101C800
2014.02.04 20:42:14.283 0: HMLAN_Parse: HMLAN1 R:RFE6C1A1F stat:0002 t:00000000 d:FF r:7FFF m:BE 8002 706958 239D9F 0101C800
ich werde mal mit "virtuel actor" spielen - wenn das die Lösung ist - auch gut
Hm - irgendwie ist der 4-fach Sender komisch...
direktes peering mit einem Aktor funktioniert nicht, wenn der Sender schon mit dem FHEM gepairt ist
Versuch:
set HS_Alarm_5_Btn_04 peerChan 1 SW_Stromvert_Sw_02 single set
als Antwort kommt
2014-02-04 22:08:45.615 CUL_HM HS_Alarm_5 ResndFail
2014-02-04 22:08:45.632 CUL_HM HS_Alarm_5 MISSING ACK
ein Tastendruck hat keinen Effekt beim Aktor
Setze ich den Sender zurück lässt sich der Sender peeren. Auf dem FHEM sehe ich den Sender dann natürlich nur als "Broadcast" und ich habe keine gesicherte Übertragung
Zitatdirektes peering mit einem Aktor funktioniert nicht, wenn der Sender schon mit dem FHEM gepairt ist
wenn er gepairt ist sollte das peeren über kommandos funktionieren.
Bitte rohmessages vom peeren - so kann ich nichts sehen
WOW - kann man "schlecht" pairen ???
Ausgangssituation:
peering hat nicht funktioniert und oft kamen die Nachrichten mehrfach.
Tests:
für die gewünschten Logs habe ich den Sender zurückgesetzt und den Sender aus der CFG gelöscht.
Manchmal sind Ablenkungen durch andere Personen hilfreich....
Habe vergessen ein "reread" zu starten und dann das Pairing am Sender gestartet.
Aber der Sender hat sich gepairt.
Dann habe ich das peering aufgerufen
HS_Alarm_5_Btn_04 = 239D9F03
SW_Stromvert_Sw_02 = 1F3DC502
set HS_Alarm_5_Btn_04 peerChan 0 SW_Stromvert_Sw_02 single set
Log vom Sender:
2014-02-05_20:31:22 HS_Alarm_5_Btn_04 R-SW_Stromvert_Sw_02-expectAES: set_off
2014-02-05_20:31:22 HS_Alarm_5_Btn_04 R-SW_Stromvert_Sw_02-peerNeedsBurst: set_off
fhem.log:
2014.02.05 20:31:22.153 0: HMLAN_Send: HMLAN1 S:S038884EC stat: 00 t:00000000 d:01 r:038884EC m:20 A001 706958 1F3DC5 0201239D9F0303
2014.02.05 20:31:22.309 0: HMLAN_Parse: HMLAN1 R:R038884EC stat:0001 t:04EBBE57 d:FF r:FFCE m:20 8002 1F3DC5 706958 00
2014.02.05 20:31:26.162 0: HMLAN_Send: HMLAN1 S:S03889495 stat: 00 t:00000000 d:01 r:03889495 m:21 A001 706958 1F3DC5 02040000000001
2014.02.05 20:31:26.320 0: HMLAN_Parse: HMLAN1 R:E1F3DC5 stat:0000 t:04EBCDFE d:FF r:FFCE m:21 A010 1F3DC5 706958 030800
2014.02.05 20:31:26.443 0: HMLAN_Parse: HMLAN1 R:R03889495 stat:0001 t:04EBCE03 d:FF r:FFCE m:21 A010 1F3DC5 706958 030800
2014.02.05 20:31:26.574 0: HMLAN_Parse: HMLAN1 R:E1F3DC5 stat:0000 t:04EBCEFC d:FF r:FFCE m:22 A010 1F3DC5 706958 030000
2014.02.05 20:31:26.671 0: HMLAN_Send: HMLAN1 S:S03889644 stat: 00 t:00000000 d:01 r:03889644 m:22 A001 706958 1F3DC5 0203
2014.02.05 20:31:27.093 0: HMLAN_Parse: HMLAN1 R:E1F3DC5 stat:0000 t:04EBD103 d:FF r:FFCE m:22 A010 1F3DC5 706958 01239D9F0300000000
2014.02.05 20:31:27.190 0: HMLAN_Delay: HMLAN1 1F3DC5
2014.02.05 20:31:27.304 0: HMLAN_Parse: HMLAN1 R:R03889644 stat:0001 t:04EBD108 d:FF r:FFCE m:22 A010 1F3DC5 706958 01239D9F0300000000
2014.02.05 20:31:27.306 0: HMLAN_SdDly: HMLAN1 1F3DC5
2014.02.05 20:31:27.308 0: HMLAN_Send: HMLAN1 S:S0388984E stat: 00 t:00000000 d:01 r:0388984E m:23 A001 706958 1F3DC5 0204239D9F0303
2014.02.05 20:31:27.615 0: HMLAN_Parse: HMLAN1 R:E1F3DC5 stat:0000 t:04EBD30D d:FF r:FFCE m:23 A010 1F3DC5 706958 03020000326400FF00FF011463
2014.02.05 20:31:27.730 0: HMLAN_Parse: HMLAN1 R:R0388984E stat:0001 t:04EBD312 d:FF r:FFCE m:23 A010 1F3DC5 706958 03020000326400FF00FF011463
2014.02.05 20:31:27.869 0: HMLAN_Parse: HMLAN1 R:E1F3DC5 stat:0000 t:04EBD40B d:FF r:FFCE m:24 A010 1F3DC5 706958 03820000326400FF00FF211463
2014.02.05 20:31:28.110 0: HMLAN_Parse: HMLAN1 R:E1F3DC5 stat:0000 t:04EBD4FC d:FF r:FFCE m:25 A010 1F3DC5 706958 030000
erst jetzt ist mir mein "Missgeschick" mit dem fehlenden reread aufgefallen....
Aber alles funktioniert! - Auch das peering - Und keine mehrfach gesendeten Nachrichten mehr!
Also die Gegemprobe:
Diesmal "richtig":
Sender zurückgesetzt - CFG in FHEM gelöscht - "REREAD"
Dann
set HMLAN1 hmPairForSec 300
aufgerufen und Pairing am Sender gestartet.
Test: Pairing OK - aber wieder mehrfach gesendete Nachrichten vom Sender.
wieder "alte" Config in fhem.cfg - "reread".
Immer noch mehrfach gesendete Nachrichten.
Peering gestartet:
2014-02-05_21:18:10 HS_Alarm_5_Btn_04 R-SW_Stromvert_Sw_02-expectAES: set_off
2014-02-05_21:18:10 HS_Alarm_5_Btn_04 R-SW_Stromvert_Sw_02-peerNeedsBurst: set_off
2014.02.05 21:18:10.387 0: HMLAN_Send: HMLAN1 S:S03B35E96 stat: 00 t:00000000 d:01 r:03B35E96 m:0F A001 706958 1F3DC5 0201239D9F0303
2014.02.05 21:18:10.544 0: HMLAN_Parse: HMLAN1 R:R03B35E96 stat:0001 t:00038A8A d:FF r:FFCE m:0F 8002 1F3DC5 706958 00
2014.02.05 21:18:14.396 0: HMLAN_Send: HMLAN1 S:S03B36E3F stat: 00 t:00000000 d:01 r:03B36E3F m:10 A001 706958 1F3DC5 02040000000001
2014.02.05 21:18:14.553 0: HMLAN_Parse: HMLAN1 R:E1F3DC5 stat:0000 t:00039A2F d:FF r:FFCD m:10 A010 1F3DC5 706958 030800
2014.02.05 21:18:14.676 0: HMLAN_Parse: HMLAN1 R:R03B36E3F stat:0001 t:00039A34 d:FF r:FFCD m:10 A010 1F3DC5 706958 030800
2014.02.05 21:18:14.807 0: HMLAN_Parse: HMLAN1 R:E1F3DC5 stat:0000 t:00039B2D d:FF r:FFCE m:11 A010 1F3DC5 706958 030000
2014.02.05 21:18:14.903 0: HMLAN_Send: HMLAN1 S:S03B36FED stat: 00 t:00000000 d:01 r:03B36FED m:11 A001 706958 1F3DC5 0203
2014.02.05 21:18:15.332 0: HMLAN_Parse: HMLAN1 R:E1F3DC5 stat:0000 t:00039D39 d:FF r:FFCE m:11 A010 1F3DC5 706958 01239D9F0300000000
2014.02.05 21:18:15.427 0: HMLAN_Delay: HMLAN1 1F3DC5
2014.02.05 21:18:15.449 0: HMLAN_Parse: HMLAN1 R:R03B36FED stat:0001 t:00039D3E d:FF r:FFCE m:11 A010 1F3DC5 706958 01239D9F0300000000
2014.02.05 21:18:15.451 0: HMLAN_SdDly: HMLAN1 1F3DC5
2014.02.05 21:18:15.453 0: HMLAN_Send: HMLAN1 S:S03B371FC stat: 00 t:00000000 d:01 r:03B371FC m:12 A001 706958 1F3DC5 0204239D9F0303
2014.02.05 21:18:15.858 0: HMLAN_Parse: HMLAN1 R:E1F3DC5 stat:0000 t:00039F47 d:FF r:FFCE m:12 A010 1F3DC5 706958 03020000326400FF00FF011463
2014.02.05 21:18:15.972 0: HMLAN_Parse: HMLAN1 R:R03B371FC stat:0001 t:00039F4C d:FF r:FFCE m:12 A010 1F3DC5 706958 03020000326400FF00FF011463
2014.02.05 21:18:16.112 0: HMLAN_Parse: HMLAN1 R:E1F3DC5 stat:0000 t:0003A045 d:FF r:FFCD m:13 A010 1F3DC5 706958 03820000326400FF00FF211463
2014.02.05 21:18:16.352 0: HMLAN_Parse: HMLAN1 R:E1F3DC5 stat:0000 t:0003A136 d:FF r:FFCD m:14 A010 1F3DC5 706958 030000
Druck auf entsprechende Taste:
2014.02.05 21:20:24.548 0: HMLAN_Parse: HMLAN1 R:E239D9F stat:0000 t:0005960C d:FF r:FFAD m:46 A240 239D9F 706958 031F
2014.02.05 21:20:24.644 0: HMLAN_Send: HMLAN1 S:S03B56AB2 stat: 00 t:00000000 d:01 r:03B56AB2 m:46 8002 706958 239D9F 0101C800
2014.02.05 21:20:24.751 0: HMLAN_Send: HMLAN1 S:+239D9F,00,01,
2014.02.05 21:20:24.753 0: HMLAN_Send: HMLAN1 S:S03B56B73 stat: 00 t:00000000 d:01 r:03B56B73 m:13 A001 706958 239D9F 03011F3DC50200
2014.02.05 21:20:24.939 0: HMLAN_Parse: HMLAN1 R:R03B56AB2 stat:0002 t:00000000 d:FF r:7FFF m:46 8002 706958 239D9F 0101C800
2014.02.05 21:20:25.789 0: HMLAN_Parse: HMLAN1 R:R03B56B73 stat:0008 t:00000000 d:FF r:7FFF m:13 A001 706958 239D9F 03011F3DC50200
2014.02.05 21:20:25.791 0: HMLAN_Parse: HMLAN1 no ACK from 239D9F
aber keine Wirkung am Aktor.
Immer noch mehrfach gesendete Nachrichten.
Weitere Tests:
Sender zurückgesetzt - Pairing am Sender gestartet.
keine Eingaben am FHEM vorgenommen.
peering gelöscht und neu eingerichtet
set HS_Alarm_5_Btn_04 peerChan 0 SW_Stromvert_Sw_02 single unset
set HS_Alarm_5_Btn_04 peerChan 0 SW_Stromvert_Sw_02 single set
Test: alles gut!
peering funtzt - keine mehrfachen Nachrichten.
Mein Fazit:
Das Problem liegt wohl beim Paring des Senders.
Als Lösung: nach ersten Pairen und Einrichten des Senders, Sender zurücksetzen und erneut Pairing am Sender starten.
hi,
viel Info - mal sehen:
Zitatfür die gewünschten Logs habe ich den Sender zurückgesetzt und den Sender aus der CFG gelöscht.
sollte nicht notwendig sein - wird eh überschrieben. Eingetragen lassen ist evtl sogar einfachen, da weniger timing probleme.
ZitatHS_Alarm_5_Btn_04 R-SW_Stromvert_Sw_02-expectAES: set_off
set_ bedeutet: unklar ob das setzen schon durchgeführt ist. Sind noch commands pending? muss noch einmal anlernen gedrückt werden?... Situation "in der Schwebe" musst du klären...
Zitatfhem.log:...
'sehr schönes' peeren des 1F3DC5 mit 239D9F (nur diese Richtung!!!!!)
Danach - wie es sich gehört ein getConfig automatisch.
==>
1F3DC5 ist gepeert, registers sind aktuell -
Prima==>
239D9F hat
nichts gemacht. sicher muss man
anlernen drücken, sonst reagiert er nicht. Was ist es den für ein
Model?ZitatAber alles funktioniert!
kann man nicht sehen/sagen - nur ein teil ist im Log!
ZitatImmer noch mehrfach gesendete Nachrichten.
ehrlich? Welche? Kennst du dich mit rohmessages lesen aus?
Ich sehen keine einzige doppelte :(
ZitatDruck auf entsprechende Taste:
239D9F ist nicht gepeert - du hast nur die Hälfte gemacht. Hast du einmal pending commands nachgesehen?
Es ist schwer die Übersicht in CUL_HM zu behalten - also mache
define hm HMInfo
set hm protoEvents shortund achte auf pending kommands! auch der 239D9F will programmiert sein (und gelesen)
Da sehe ich übrigens, dass der 239D9F versucht wird zu peeren, dies aber verweigert. Das ist sicher die neuste SW und der 239D9F soll lazy-config unterstützen. Scheint aber nicht zu funktioniern... da hätte ich gerne logs mit milisekunden auflösung - ist das Möglich?
ZitatTest: alles gut!
prima
Zitatpeering funtzt - keine mehrfachen Nachrichten.
gab nie welche
ZitatDas Problem liegt wohl beim Paring des Senders.
wo?
ZitatAls Lösung: nach ersten Pairen und Einrichten des Senders, Sender zurücksetzen und erneut Pairing am Sender starten.
warum? Kann ich nicht erkennen.
Gruss Martin
Hallo Martin,
Zitatsollte nicht notwendig sein - wird eh überschrieben. Eingetragen lassen ist evtl sogar einfachen, da weniger timing probleme.
das wäre dann ja wie ich es "aus Versehen" gemacht habe als ich nach dem Löschen aus dem FHEM vergessen habe "reread" aufzurufen.
Dann war ja alles OK
ZitatSind noch commands pending?
teste ich mal.....
ZitatWas ist es den für ein Model?
model HM-SEC-SC Aufdruck "HM-RC-Sec4-2"
ZitatAber alles funktioniert!
kann man nicht sehen/sagen - nur ein teil ist im Log!
das habe ich nicht gelogt - einfach nur ausprobiert
Zitatehrlich? Welche? Kennst du dich mit rohmessages lesen aus?
nein - nicht wirklich
wenn es da ein Kompendium gibt, kannst es mir ja mal zukommen lassen. Dann kann ich mehr testen bevor ich frage
ZitatIch sehen keine einzige doppelte :(
auch die habe ich nicht gelogt - ich sehe es im Eventmonitor: Taste 2x o 3x mit gleicher Trigger-Nr
wie in meinem 1sten u 2ten Post beschrieben
Zitatda hätte ich gerne logs mit milisekunden auflösung - ist das Möglich?
kannst Du haben - wenn Du mir verrätst wie.
Der Sender logt in eine andere Datei - die zeichnet keine ms auf
für die log rufe ich immer
define hm HMinfo
attr global verbose 1
attr global mseclog 1
attr HMLAN1 logIDs allauf
Zitatmodel HM-SEC-SC
Aufdruck "HM-RC-Sec4-2"
verstehe ich nicht - das passt doch nicht. kannst du einmal eine config message mitschneiden?
Zitatnein - nicht wirklich
wenn es da ein Kompendium gibt, kannst es mir ja mal zukommen lassen
habe leider keins... . Aber bitte vorsicht mit statements, wenn man es nicht versteht.
Zitatauch die habe ich nicht gelogt - ich sehe es im Eventmonitor: Taste 2x o 3x mit gleicher Trigger-Nr
wie in meinem 1sten u 2ten Post beschrieben
wenn du hier logs veröffentlichst und dahinter schreibst da wären doppelte, aber das garnicht gelogt hast macht es keinen sinn. Schicke bitte die logs, die du besprechen willst - insbesondere wenn du es evtl Fehl-interpretierst. So gibt es nur staunen der Leser.
Zitatkannst Du haben - wenn Du mir verrätst wie.
sorry, waren eingeschaltet - habe ich wohl abgeschnitten beim Aufarbeiten..
das Problem des LazyConfig kömmte sicher daher, dass du einen RC4 als SC eingetragen hast.
Ist das automatisch passiert?
Also bitte eine Anlernmessage und das list des Device - vielleicht passt etwas nicht
Gruss Martin
sorry - ist natürlich schwachsinn!
da stand "HM-RC-Sec4-2"
hab's falsch rauskopiert
trace für pairing:
2014.02.06 20:39:21.810 0: HMLAN_Parse: HMLAN1 R:E239D9F stat:0000 t:05068CC8 d:FF r:FFB8 m:00 8400 239D9F 000000 1100A54B45513038373136373440040000
2014.02.06 20:39:22.120 0: HMLAN_Send: HMLAN1 S:S08B633CB stat: 00 t:00000000 d:01 r:08B633CB m:0F A001 706958 239D9F 00050000000000
2014.02.06 20:39:22.276 0: HMLAN_Parse: HMLAN1 R:R08B633CB stat:0001 t:05068EA2 d:FF r:FFB8 m:0F 8002 239D9F 706958 00
2014.02.06 20:39:22.376 0: HMLAN_Send: HMLAN1 S:S08B634B1 stat: 00 t:00000000 d:01 r:08B634B1 m:10 A001 706958 239D9F 000802010A700B690C58
2014.02.06 20:39:22.674 0: HMLAN_Parse: HMLAN1 R:R08B634B1 stat:0001 t:05069030 d:FF r:FFB8 m:10 8002 239D9F 706958 00
2014.02.06 20:39:22.775 0: HMLAN_Send: HMLAN1 S:S08B635FF stat: 00 t:00000000 d:01 r:08B635FF m:11 A001 706958 239D9F 0006
2014.02.06 20:39:23.073 0: HMLAN_Parse: HMLAN1 R:R08B635FF stat:0001 t:050691BF d:FF r:FFB8 m:11 8002 239D9F 706958 00
2014.02.06 20:39:23.174 0: HMLAN_Send: HMLAN1 S:S08B6378E stat: 00 t:00000000 d:01 r:08B6378E m:12 A001 706958 239D9F 00040000000000
2014.02.06 20:39:23.481 0: HMLAN_Parse: HMLAN1 R:E239D9F stat:0000 t:05069352 d:FF r:FFB8 m:12 A010 239D9F 706958 0202010A700B690C5818000000
2014.02.06 20:39:23.577 0: HMLAN_Delay: HMLAN1 239D9F
2014.02.06 20:39:23.596 0: HMLAN_Parse: HMLAN1 R:R08B6378E stat:0001 t:05069357 d:FF r:FFB8 m:12 A010 239D9F 706958 0202010A700B690C5818000000
2014.02.06 20:39:23.598 0: HMLAN_SdDly: HMLAN1 239D9F
2014.02.06 20:39:23.599 0: HMLAN_Send: HMLAN1 S:+239D9F,00,01,
2014.02.06 20:39:23.601 0: HMLAN_Send: HMLAN1 S:S08B63933 stat: 00 t:00000000 d:01 r:08B63933 m:13 A001 706958 239D9F 01040000000001
2014.02.06 20:39:23.998 0: HMLAN_Parse: HMLAN1 R:E239D9F stat:0000 t:05069558 d:FF r:FFB8 m:13 A010 239D9F 706958 020410080009000000
2014.02.06 20:39:24.095 0: HMLAN_Delay: HMLAN1 239D9F
2014.02.06 20:39:24.116 0: HMLAN_Parse: HMLAN1 R:R08B63933 stat:0001 t:0506955D d:FF r:FFB8 m:13 A010 239D9F 706958 020410080009000000
2014.02.06 20:39:24.118 0: HMLAN_SdDly: HMLAN1 239D9F
2014.02.06 20:39:24.120 0: HMLAN_Send: HMLAN1 S:S08B63B35 stat: 00 t:00000000 d:01 r:08B63B35 m:14 A001 706958 239D9F 0103
2014.02.06 20:39:24.516 0: HMLAN_Parse: HMLAN1 R:E239D9F stat:0000 t:0506975E d:FF r:FFB8 m:14 A010 239D9F 706958 0100000000
2014.02.06 20:39:24.612 0: HMLAN_Delay: HMLAN1 239D9F
2014.02.06 20:39:24.636 0: HMLAN_Parse: HMLAN1 R:R08B63B35 stat:0001 t:05069763 d:FF r:FFB8 m:14 A010 239D9F 706958 0100000000
2014.02.06 20:39:24.638 0: HMLAN_SdDly: HMLAN1 239D9F
2014.02.06 20:39:24.640 0: HMLAN_Send: HMLAN1 S:+239D9F,00,01,
2014.02.06 20:39:24.641 0: HMLAN_Send: HMLAN1 S:S08B63D35 stat: 00 t:00000000 d:01 r:08B63D35 m:15 A001 706958 239D9F 02040000000001
2014.02.06 20:39:25.041 0: HMLAN_Parse: HMLAN1 R:E239D9F stat:0000 t:0506996B d:FF r:FFB8 m:15 A010 239D9F 706958 020410080009000000
2014.02.06 20:39:25.137 0: HMLAN_Delay: HMLAN1 239D9F
2014.02.06 20:39:25.159 0: HMLAN_Parse: HMLAN1 R:R08B63D35 stat:0001 t:05069970 d:FF r:FFB8 m:15 A010 239D9F 706958 020410080009000000
2014.02.06 20:39:25.161 0: HMLAN_SdDly: HMLAN1 239D9F
2014.02.06 20:39:25.163 0: HMLAN_Send: HMLAN1 S:S08B63F47 stat: 00 t:00000000 d:01 r:08B63F47 m:16 A001 706958 239D9F 0203
2014.02.06 20:39:25.560 0: HMLAN_Parse: HMLAN1 R:E239D9F stat:0000 t:05069B72 d:FF r:FFB8 m:16 A010 239D9F 706958 0100000000
2014.02.06 20:39:25.680 0: HMLAN_Parse: HMLAN1 R:R08B63F47 stat:0001 t:05069B77 d:FF r:FFB8 m:16 A010 239D9F 706958 0100000000
in der Config steht dann:
define CUL_HM_HM_RC_Sec4_2_239D9F CUL_HM 239D9F
attr CUL_HM_HM_RC_Sec4_2_239D9F .devInfo 040000
attr CUL_HM_HM_RC_Sec4_2_239D9F .stc 40
attr CUL_HM_HM_RC_Sec4_2_239D9F IODev HMLAN1
attr CUL_HM_HM_RC_Sec4_2_239D9F autoReadReg 4_reqStatus
attr CUL_HM_HM_RC_Sec4_2_239D9F expert 2_full
attr CUL_HM_HM_RC_Sec4_2_239D9F firmware 1.1
attr CUL_HM_HM_RC_Sec4_2_239D9F model HM-RC-Sec4-2
attr CUL_HM_HM_RC_Sec4_2_239D9F peerIDs
attr CUL_HM_HM_RC_Sec4_2_239D9F room CUL_HM
attr CUL_HM_HM_RC_Sec4_2_239D9F serialNr KEQ0871674
attr CUL_HM_HM_RC_Sec4_2_239D9F subType remote
define FileLog_CUL_HM_HM_RC_Sec4_2_239D9F FileLog ./log/CUL_HM_HM_RC_Sec4_2_239D9F-%Y-%m.log CUL_HM_HM_RC_Sec4_2_239D9F
attr FileLog_CUL_HM_HM_RC_Sec4_2_239D9F logtype text
attr FileLog_CUL_HM_HM_RC_Sec4_2_239D9F room CUL_HM
define CUL_HM_HM_RC_Sec4_2_239D9F_Btn_01 CUL_HM 239D9F01
attr CUL_HM_HM_RC_Sec4_2_239D9F_Btn_01 model HM-RC-Sec4-2
attr CUL_HM_HM_RC_Sec4_2_239D9F_Btn_01 peerIDs 00000000,
define CUL_HM_HM_RC_Sec4_2_239D9F_Btn_02 CUL_HM 239D9F02
attr CUL_HM_HM_RC_Sec4_2_239D9F_Btn_02 model HM-RC-Sec4-2
attr CUL_HM_HM_RC_Sec4_2_239D9F_Btn_02 peerIDs 00000000,
meine Config, die ich bisher benutzt habe:
define HS_Alarm_5 CUL_HM 239D9F
attr HS_Alarm_5 .devInfo 040000
attr HS_Alarm_5 .stc 40
attr HS_Alarm_5 alias Ulf
attr HS_Alarm_5 autoReadReg 4_reqStatus
attr HS_Alarm_5 expert 2_full
attr HS_Alarm_5 firmware 1.1
attr HS_Alarm_5 model HM-RC-Sec4-2
attr HS_Alarm_5 peerIDs
attr HS_Alarm_5 room CUL_HM
attr HS_Alarm_5 serialNr KEQ0871805
attr HS_Alarm_5 subType remote
attr HS_Alarm_5 webCmd getConfig
define FileLog_HS_Alarm_5 FileLog ./log/alarm-%Y-%m.log HS_Alarm_5
attr FileLog_HS_Alarm_5 logtype text
attr FileLog_HS_Alarm_5 room CUL_HM
define HS_Alarm_5_Btn_01 CUL_HM 239D9F02
attr HS_Alarm_5_Btn_01 expert 1
attr HS_Alarm_5_Btn_01 model HM-RC-Sec4-2
attr HS_Alarm_5_Btn_01 peerIDs
attr HS_Alarm_5_Btn_01 room CUL_HM
define FileLog_HS_Alarm_5_Btn_01 FileLog ./log/alarm-%Y-%m.log HS_Alarm_5_Btn_01
attr FileLog_HS_Alarm_5_Btn_01 logtype text
attr FileLog_HS_Alarm_5_Btn_01 room CUL_HM
define HS_Alarm_5_Btn_02 CUL_HM 239D9F01
attr HS_Alarm_5_Btn_02 expert 1
attr HS_Alarm_5_Btn_02 model HM-RC-Sec4-2
attr HS_Alarm_5_Btn_02 peerIDs
attr HS_Alarm_5_Btn_02 room CUL_HM
define FileLog_HS_Alarm_5_Btn_02 FileLog ./log/alarm-%Y-%m.log HS_Alarm_5_Btn_02
attr FileLog_HS_Alarm_5_Btn_02 logtype text
attr FileLog_HS_Alarm_5_Btn_02 room CUL_HM
define HS_Alarm_5_Btn_03 CUL_HM 239D9F04
attr HS_Alarm_5_Btn_03 expert 1
attr HS_Alarm_5_Btn_03 model HM-RC-Sec4-2
attr HS_Alarm_5_Btn_03 peerIDs
attr HS_Alarm_5_Btn_03 room CUL_HM
define FileLog_HS_Alarm_5_Btn_03 FileLog ./log/alarm-%Y-%m.log HS_Alarm_5_Btn_03
attr FileLog_HS_Alarm_5_Btn_03 logtype text
attr FileLog_HS_Alarm_5_Btn_03 room CUL_HM
define HS_Alarm_5_Btn_04 CUL_HM 239D9F03
attr HS_Alarm_5_Btn_04 expert 1
attr HS_Alarm_5_Btn_04 model HM-RC-Sec4-2
attr HS_Alarm_5_Btn_04 peerIDs
attr HS_Alarm_5_Btn_04 room CUL_HM
define FileLog_HS_Alarm_5_Btn_04 FileLog ./log/alarm-%Y-%m.log HS_Alarm_5_Btn_04
attr FileLog_HS_Alarm_5_Btn_04 logtype text
attr FileLog_HS_Alarm_5_Btn_04 room CUL_HM
auch die wurde automatisch erstellt und von mit um die 2 fehlenden Tasten erweitert.
Hi,
ok - die beiden fehlenden Buttons waren ein Fehler im Config file.
Das einrichten ist ansonsten ohne Probleme abgelaufen - ohne doppelte messages.
folgende Attibute sind quasi intern und sollten immer von FHEM gesetzt werden.
attr HS_Alarm_5 .devInfo 040000
attr HS_Alarm_5 .stc 40
attr HS_Alarm_5 firmware 1.1
attr HS_Alarm_5 model HM-RC-Sec4-2
attr HS_Alarm_5 peerIDs
attr HS_Alarm_5 serialNr KEQ0871805
attr HS_Alarm_5 subType remote
Gruss Martin
Hallo zusammen,
ich hoffe ich darf dieses alte Thema nochmal ausgraben. ???
Ich habe ebenfalls das Problem mit dem mehrfachen Senden des HM-RC-Sec4-2.
Ist ganz unterschiedlich (1-3 mal)
2016-02-08 14:55:44 CUL_HM Key1 battery: ok
2016-02-08 14:55:44 CUL_HM Key1 CMDs_done
2016-02-08 14:55:44 CUL_HM Key1 Key1_armInt Short
2016-02-08 14:55:44 CUL_HM Key1_armInt Short (to virtualCCU)
2016-02-08 14:55:44 CUL_HM Key1_armInt trigger: Short_7
2016-02-08 14:55:44 CUL_HM Key1_armInt trigger_cnt: 7
2016-02-08 14:55:44 CUL_HM virtualCCU_Key1_armInt trigLast: Key1_armInt:short
2016-02-08 14:55:44 CUL_HM virtualCCU_Key1_armInt trig_Key1_armInt: short
2016-02-08 14:55:44 CUL_HM Key1 battery: ok
2016-02-08 14:55:44 CUL_HM Key1 CMDs_done
2016-02-08 14:55:44 CUL_HM Key1 Key1_armInt Short
2016-02-08 14:55:44 CUL_HM Key1_armInt Short (to virtualCCU)
2016-02-08 14:55:44 CUL_HM Key1_armInt trigger: Short_7
2016-02-08 14:55:44 CUL_HM Key1_armInt trigger_cnt: 7
2016-02-08 14:55:44 CUL_HM virtualCCU_Key1_armInt trigLast: Key1_armInt:short
2016-02-08 14:55:44 CUL_HM virtualCCU_Key1_armInt trig_Key1_armInt: short
Einen der Channels habe ich testweise mal mit der VCCU gepeered. Die anderen noch nicht. Allerdings macht das keinen Unterschied am Verhalten.
Der Tipp mit msgrepeat funktioniert bei mir leider nicht. Ich habe den Sender auch schonmal zurückgesetzt und neu an FHEM angelernt.
Wie habt ihr damals das Problem in den Griff bekommen? Ich werde da leider nicht ganz schlau draus.
Wenn weitere Infos benötigt werden kann ich gerne posten. :)
Danke schonmal für die Hilfe, ich komm hier grad echt nicht weiter. ::)
Ich habe das gleiche Problem gehabt und mir blieb letztendlich nur der Weg über die Datei 00_HMLAN.pm. Dort fange ich die Wiederholungen direkt ab und verwerfe sie. Ein Verwerfen im Notify war bei mir nicht möglich, da die entscheidenden Werte nicht durchgereicht werden.
Bei Bedarf kann ich die Änderungen gerne zur Verfügung stellen.
Grüße
Zitat von: rx am 08 Februar 2016, 20:08:37
Ich habe das gleiche Problem gehabt und mir blieb letztendlich nur der Weg über die Datei 00_HMLAN.pm. Dort fange ich die Wiederholungen direkt ab und verwerfe sie.
Wird das File nicht beim Update überschrieben? Eine Lösung die Wiederholungen zu Verhindern wäre mir am Ende lieber. :)
ZitatBei Bedarf kann ich die Änderungen gerne zur Verfügung stellen.
Ich würde es mir auf jedenfall gerne mal anschauen. Ich hoffe ich kann es dann auch umsetzen. :)
Grüße
Das mit dem Update ist natürlich ein Problem. Vielleicht gibt es ja eine Möglichkeit die Anpassungen dauerhaft einzubinden. Ich schicks dir per PM.
Grüße
In hmlan messages abzufangen ist nicht der korrekte weg, zumindest nur die halbe Miete. Wenn du mehrere IOs hast, evtl cul, ist der Spass zu Ende.
Prinzipiell verwirft culhm doppelte messages. Sollte das nicht klappen sendet zu diesem Fall die rohmessages (sniffen).
Trotz allen kann es zu doppelten events kommen, da ACK und status die gleichen readings bedienen. Daher sollte jeder immer eventonchangereading auf .* setzen. Das ist m.e. Pflicht und verbessert das verhalten nachhaltig. Verloren geht auch nichts. Eine codeaenderung steht demnach nicht an
Hallo Martin, danke für deine Infos. Ich kann gerne die Rohmessages schicken, da das Verhalten sehr einfach zu produzieren ist (Handsender befindet sich weiter weg vom Haus).
Ein eventonchangereading hat in dem Fall nichts gebracht - das hatte ich bereits aktiviert. Vielleicht hilft es dir, wenn ich sage wo ich was eingebaut habe, um den Fehler (als Laie) abzuschalten.
Und zwar habe ich in der Datei 00_HMLAN.pm zu Beginn der Funktion HMLAN_Parse folgendes geprüft:
Wenn $src einer meiner Handsender ist und die ersten beiden Zeichen von $p 01, 02, 03 oder 04 sind dann schaue ich ob $p dem letzten $p entspricht. Ist dies der Fall, dann verwerfe ich die Message da sie offensichtlich doppelt gesendete wurde. Anscheinend steht hinter den ersten beiden Stellen von $p eine Art Sequenznummer, auf die ich aber innerhalb eines Notify keinen Zugriff habe. Ich habe extra die Einschränkung auf die $src meiner Handsender gemacht, da ich natürlich keine Ahnung habe, ob es negative Seiteneffekte gibt und ich den Rest meiner Installation nicht gefährden wollte.
Danke fürs Lesen und Grüße
Frank
Das ist alles richtig, aber nicht vollständig. Ein longpress schickt viele messages die alle gemeldet werden sollen.
Hmlan ist definitiv nicht dafür gemacht Aktoren zu kennen. Hier wird es mit Sicherheit nicht eingebaut.
Wie gesagt, 2 IOs hast du damit nicht im griff. Zu viele Löcher im Konzept.
Logge einmal die rohmessages und schicke die events, die ausgelöst werden.
bei mir treten die wiederholungen unter anderem mit meiner HM 4 Tasten Fernbedienung auf. via notify werte ich den tastendruck aus.
habe mittlerweile festgestellt, dass die wiederholungen erst nach einem HMLAN timeout bzw. disconnect auftreten. gerade in verbindung mit AES scheint es da probleme zu geben.
mache ich ein "get config" der fernbedienung bzw. ein "shutdown restart" des fhem servers sind die wiederholungen weg.
evtl. hilft diese info die problematik etwas einzukreisen.
grüße
chris
kannst du ein Beispiel der ungewollten wiederholungen zeigen und logs mitschicken?