Hallo Freunde der Hausautomation,
diverse Sensoren und Aktoren laufen problemlos mit AES, aber bei dem WM55 bekomme ich das einfach nicht hin. Der Schalter (switch) ist mit mit der VCCU (vccu) gepairt und die beiden Kanäle (switch_sharp, switch_usharp) sind mit virtuellen Buttons der vccu (vccu_Btn1, vccu_Btn2) gepeert.
Solange ich "expectAES" auf den switch Buttons ausgeschalten habe, wird jedes drücken einer der Buttons grün quittiert. Sobald ich allerdings expectAES anmache, kommt nach 1-2 Sekunden gelb, eine 1-2 Sekunden lange rote Quittierung.
Ich habe schon verschiedene Threads im Forum (z.B. thread 1 (http://forum.fhem.de/index.php?topic=26816.0), thread 2 (http://forum.fhem.de/index.php/topic,25537.0.html), thread 3 (http://forum.fhem.de/index.php/topic,32011.msg244401.html#msg244401), die sich mit einem (ähnlichem) Problem beschäftigen durchgearbeitet, aber ich bin zu keiner Lösung gekommen.
Egal ob expectAES an oder aus ist, im Event Monitor erscheint nichts bezüglich AES - es wird immer nur der jeweilige Trigger registriert:
2015-02-26 21:58:44.980 CUL_HM switch_usharp trigger_cnt: 151
2015-02-26 21:58:44.980 CUL_HM switch_usharp Short (to vccu)
2015-02-26 21:58:44.980 CUL_HM switch_usharp trigger: Short_151
2015-02-26 21:58:44.983 CUL_HM vccu_Btn2 trig_switch_usharp: short
2015-02-26 21:58:44.983 CUL_HM vccu_Btn2 trigLast: switch_usharp :short
Aber bei jedem get config, gibts ein:
2015-02-26 21:10:28 CUL_HM switch aesCommToDev: ok
Hier die Details von hminfo:
configCheck done:
peerCheck done:
peerXref done:
x-ref list
switch_sharp => vccu_Btn1
switch_usharp => vccu_Btn2
vccu_Btn1 => switch_sharp
vccu_Btn2 => switch_usharp
param done:
param list
entity : peerList |
switch : -
switch_sharp : vccu_Btn1,
switch_usharp : vccu_Btn2,
vccu : -
vccu_Btn1 : switch_sharp,
vccu_Btn2 : switch_usharp,
vccu_Btn3 : -
vccu_Btn4 : -
Hier noch die wichtigsten interals für die Rohdaten am Ende:
switch:
Internals:
DEF 29A75F
switch_sharp:
Internals:
DEF 29A75F01
switch_usharp:
Internals:
DEF 29A75F02
vccu:
Internals:
DEF 9D6EBB
IODev hmusb
hmusb:
Readings:
2015-02-26 21:09:00 D-HMIdAssigned 9D6EBB
2015-02-26 21:09:00 D-HMIdOriginal 26354C
Ich habe auch eine Textdatei mit den (meisten) Internals, Readings und Attributes von vccu, hmusb und switch angehängt. Obwohl ich eigentlich nur einen AES Keywechsel durchgeführt habe (auf meinen eigenen Key), habe ich auch mal probiert diesen nochmals als hmkey02 an dem hmusb einzugeben, aber das brachte auch keine Änderung. In der Bidcos-Service > keys Datei, steht auch nur:
Current Index = 1
Key 0 =
Key 1 = xxx
Last Index = 0
In der entsprechenden .dev Datei für den switch findet sich dies:
<device serial="LEQ0396191" type="HM-RC-X" address="0x29A75F" aes_key_index="1" firmware_version="1.4" bidcos_interface="KEQ1110916"
Folgende Rohlogs habe ich mit logIDs (sys,all) gesetzt mitgeschnitten:
Drücken des switch_usharp Buttons mit expectAES aus:
2015.02.26 21:49:09.712 0: HMLAN_Parse: hmusb R:E29A75F stat:0000 t:00D60EDF d:FF r:FFC0 m:97 A640 29A75F 9D6EBB 0295
switch_usharp getconfig mit expectAES aus:
2015.02.26 21:53:12.081 0: HMLAN_Send: hmusb I:+29A75F,03,01,1E
2015.02.26 21:53:15.182 0: HMLAN_Parse: hmusb R:E29A75F stat:0000 t:00D9CDC6 d:FF r:FFC8 m:98 A200 29A75F 9D6EBB 1400C24C45513033393631393140020000
2015.02.26 21:53:15.285 0: HMLAN_Send: hmusb S:+29A75F,03,01,1E
2015.02.26 21:53:15.286 0: HMLAN_Send: hmusb S:SC7AA3483 stat: 00 t:00000000 d:01 r:C7AA3483 m:18 A001 9D6EBB 29A75F 00040000000000
2015.02.26 21:53:15.694 0: HMLAN_Parse: hmusb R:E29A75F stat:0100 t:00D9CFC4 d:FF r:FFCB m:18 A010 29A75F 9D6EBB 0202010A9D0B6E0CBB0000
2015.02.26 21:53:16.078 0: HMLAN_Parse: hmusb R:RC7AA3483 stat:0041 t:00D9CFC9 d:01 r:FFCB m:18 A010 29A75F 9D6EBB 0202010A9D0B6E0CBB0000
2015.02.26 21:53:16.180 0: HMLAN_Send: hmusb S:+29A75F,03,01,1E
2015.02.26 21:53:16.182 0: HMLAN_Send: hmusb S:SC7AA3828 stat: 00 t:00000000 d:01 r:C7AA3828 m:19 A001 9D6EBB 29A75F 01040000000001
2015.02.26 21:53:16.494 0: HMLAN_Parse: hmusb R:E29A75F stat:0100 t:00D9D2D0 d:FF r:FFC4 m:19 A010 29A75F 9D6EBB 020410080109000000
2015.02.26 21:53:16.876 0: HMLAN_Parse: hmusb R:RC7AA3828 stat:0041 t:00D9D2D5 d:01 r:FFC4 m:19 A010 29A75F 9D6EBB 020410080109000000
2015.02.26 21:53:16.977 0: HMLAN_Send: hmusb S:SC7AA3B3F stat: 00 t:00000000 d:01 r:C7AA3B3F m:1A A001 9D6EBB 29A75F 0103
2015.02.26 21:53:17.262 0: HMLAN_Parse: hmusb R:E29A75F stat:0100 t:00D9D5DC d:FF r:FFC3 m:1A A010 29A75F 9D6EBB 019D6EBB0100000000
2015.02.26 21:53:17.646 0: HMLAN_Parse: hmusb R:RC7AA3B3F stat:0041 t:00D9D5E1 d:01 r:FFC3 m:1A A010 29A75F 9D6EBB 019D6EBB0100000000
2015.02.26 21:53:17.748 0: HMLAN_Send: hmusb S:+29A75F,03,01,1E
2015.02.26 21:53:17.749 0: HMLAN_Send: hmusb S:SC7AA3E48 stat: 00 t:00000000 d:01 r:C7AA3E48 m:1B A001 9D6EBB 29A75F 02040000000001
2015.02.26 21:53:18.062 0: HMLAN_Parse: hmusb R:E29A75F stat:0100 t:00D9D8E8 d:FF r:FFC3 m:1B A010 29A75F 9D6EBB 020410080109000000
2015.02.26 21:53:18.414 0: HMLAN_Parse: hmusb R:RC7AA3E48 stat:0041 t:00D9D8ED d:01 r:FFC3 m:1B A010 29A75F 9D6EBB 020410080109000000
2015.02.26 21:53:18.516 0: HMLAN_Send: hmusb S:SC7AA4168 stat: 00 t:00000000 d:01 r:C7AA4168 m:1C A001 9D6EBB 29A75F 0203
2015.02.26 21:53:18.830 0: HMLAN_Parse: hmusb R:E29A75F stat:0100 t:00D9DBF4 d:FF r:FFC4 m:1C A010 29A75F 9D6EBB 019D6EBB0200000000
2015.02.26 21:53:19.214 0: HMLAN_Parse: hmusb R:RC7AA4168 stat:0041 t:00D9DBF9 d:01 r:FFC4 m:1C A010 29A75F 9D6EBB 019D6EBB0200000000
2015.02.26 21:53:19.316 0: HMLAN_Send: hmusb S:+29A75F,03,01,1E
2015.02.26 21:53:19.317 0: HMLAN_Send: hmusb S:SC7AA4469 stat: 00 t:00000000 d:01 r:C7AA4469 m:1D A001 9D6EBB 29A75F 01049D6EBB0104
2015.02.26 21:53:19.598 0: HMLAN_Parse: hmusb R:E29A75F stat:0100 t:00D9DEFD d:FF r:FFC4 m:1D A010 29A75F 9D6EBB 0201000000
2015.02.26 21:53:19.982 0: HMLAN_Parse: hmusb R:RC7AA4469 stat:0041 t:00D9DF02 d:01 r:FFC4 m:1D A010 29A75F 9D6EBB 0201000000
2015.02.26 21:53:20.085 0: HMLAN_Send: hmusb S:+29A75F,03,01,1E
2015.02.26 21:53:20.086 0: HMLAN_Send: hmusb S:SC7AA4768 stat: 00 t:00000000 d:01 r:C7AA4768 m:1E A001 9D6EBB 29A75F 02049D6EBB0204
2015.02.26 21:53:20.398 0: HMLAN_Parse: hmusb R:E29A75F stat:0100 t:00D9E209 d:FF r:FFC4 m:1E A010 29A75F 9D6EBB 0201000000
2015.02.26 21:53:20.415 0: HMLAN_Send: hmusb I:+29A75F,01,01,1E
2015.02.26 21:53:20.750 0: HMLAN_Parse: hmusb R:RC7AA4768 stat:0041 t:00D9E20E d:01 r:FFC4 m:1E A010 29A75F 9D6EBB 0201000000
expectAES angeschalten und Pairtaste auf Rückseite gedrückt:
2015.02.26 21:55:05.365 0: HMLAN_Send: hmusb I:+29A75F,03,01,1E
2015.02.26 21:55:10.350 0: HMLAN_Parse: hmusb R:E29A75F stat:0000 t:00DB8F85 d:FF r:FFC6 m:99 A200 29A75F 9D6EBB 1400C24C45513033393631393140020000
2015.02.26 21:55:10.452 0: HMLAN_Send: hmusb S:SC7ABF667 stat: 00 t:00000000 d:01 r:C7ABF667 m:1F A001 9D6EBB 29A75F 02059D6EBB0204
2015.02.26 21:55:10.862 0: HMLAN_Parse: hmusb R:E29A75F stat:0100 t:00DB9181 d:FF r:FFBE m:1F A002 29A75F 9D6EBB 04D0F7910DD0F702
2015.02.26 21:55:11.085 0: HMLAN_Parse: hmusb R:RC7ABF667 stat:0021 t:00DB9186 d:01 r:FFC5 m:1F 8002 29A75F 9D6EBB 0078BB17A6
2015.02.26 21:55:11.187 0: HMLAN_Send: hmusb S:SC7ABF940 stat: 00 t:00000000 d:01 r:C7ABF940 m:20 A001 9D6EBB 29A75F 02080180
2015.02.26 21:55:11.501 0: HMLAN_Parse: hmusb R:E29A75F stat:0100 t:00DB9410 d:FF r:FFC4 m:20 A002 29A75F 9D6EBB 04A076D28BA07602
2015.02.26 21:55:11.757 0: HMLAN_Parse: hmusb R:RC7ABF940 stat:0021 t:00DB9415 d:01 r:FFC3 m:20 8002 29A75F 9D6EBB 005EFF52E6
2015.02.26 21:55:11.860 0: HMLAN_Send: hmusb S:SC7ABFBE5 stat: 00 t:00000000 d:01 r:C7ABFBE5 m:21 A001 9D6EBB 29A75F 0206
2015.02.26 21:55:12.172 0: HMLAN_Parse: hmusb R:E29A75F stat:0100 t:00DB969E d:FF r:FFC6 m:21 A002 29A75F 9D6EBB 0401F6430B01F602
2015.02.26 21:55:12.396 0: HMLAN_Parse: hmusb R:RC7ABFBE5 stat:0021 t:00DB96A3 d:01 r:FFC3 m:21 8002 29A75F 9D6EBB 00A7D0CD2B
2015.02.26 21:55:12.497 0: HMLAN_Send: hmusb S:SC7ABFE5A stat: 00 t:00000000 d:01 r:C7ABFE5A m:22 A001 9D6EBB 29A75F 02040000000001
2015.02.26 21:55:12.813 0: HMLAN_Parse: hmusb R:E29A75F stat:0100 t:00DB992D d:FF r:FFC4 m:22 A010 29A75F 9D6EBB 020410080109000000
2015.02.26 21:55:13.165 0: HMLAN_Parse: hmusb R:RC7ABFE5A stat:0041 t:00DB9932 d:01 r:FFC4 m:22 A010 29A75F 9D6EBB 020410080109000000
2015.02.26 21:55:13.268 0: HMLAN_Send: hmusb S:SC7AC01A8 stat: 00 t:00000000 d:01 r:C7AC01A8 m:23 A001 9D6EBB 29A75F 0203
2015.02.26 21:55:13.581 0: HMLAN_Parse: hmusb R:E29A75F stat:0100 t:00DB9C38 d:FF r:FFC4 m:23 A010 29A75F 9D6EBB 019D6EBB0200000000
2015.02.26 21:55:13.965 0: HMLAN_Parse: hmusb R:RC7AC01A8 stat:0041 t:00DB9C3D d:01 r:FFC4 m:23 A010 29A75F 9D6EBB 019D6EBB0200000000
2015.02.26 21:55:14.068 0: HMLAN_Send: hmusb S:SC7AC04A8 stat: 00 t:00000000 d:01 r:C7AC04A8 m:24 A001 9D6EBB 29A75F 02049D6EBB0204
2015.02.26 21:55:14.349 0: HMLAN_Parse: hmusb R:E29A75F stat:0100 t:00DB9F41 d:FF r:FFC4 m:24 A010 29A75F 9D6EBB 0201800000
2015.02.26 21:55:14.366 0: HMLAN_Send: hmusb I:+29A75F,01,01,1E
2015.02.26 21:55:14.733 0: HMLAN_Parse: hmusb R:RC7AC04A8 stat:0041 t:00DB9F46 d:01 r:FFC4 m:24 A010 29A75F 9D6EBB 0201800000
Drücken des usharp Buttons mit expectAES angeschalten:
2015.02.26 21:56:55.399 0: HMLAN_Send: hmusb I:K
2015.02.26 21:56:55.437 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110916 d:26354C O:9D6EBB t:00DD2A13 IDcnt:0008
2015.02.26 21:56:56.429 0: HMLAN_Parse: hmusb R:E29A75F stat:0000 t:00DD2DEB d:FF r:FFC3 m:9A A640 29A75F 9D6EBB 0296
2015.02.26 21:56:56.683 0: HMLAN_Parse: hmusb R:E29A75F stat:0000 t:00DD2EEB d:FF r:FFC4 m:9B A240 29A75F 9D6EBB 0296
2015.02.26 21:56:56.940 0: HMLAN_Parse: hmusb R:E29A75F stat:0000 t:00DD2FEA d:FF r:FFC3 m:9C A240 29A75F 9D6EBB 0296
getconfig mit expectAES an:
2015.02.26 21:57:57.823 0: HMLAN_Send: hmusb I:+29A75F,03,01,1E
2015.02.26 21:58:02.765 0: HMLAN_Parse: hmusb R:E29A75F stat:0000 t:00DE3107 d:FF r:FFC9 m:9D A200 29A75F 9D6EBB 1400C24C45513033393631393140020000
2015.02.26 21:58:02.868 0: HMLAN_Send: hmusb S:SC7AE97E3 stat: 00 t:00000000 d:01 r:C7AE97E3 m:25 A001 9D6EBB 29A75F 02040000000001
2015.02.26 21:58:03.277 0: HMLAN_Parse: hmusb R:E29A75F stat:0100 t:00DE3304 d:FF r:FFC8 m:25 A010 29A75F 9D6EBB 020410080109000000
2015.02.26 21:58:03.628 0: HMLAN_Parse: hmusb R:RC7AE97E3 stat:0041 t:00DE3309 d:01 r:FFC8 m:25 A010 29A75F 9D6EBB 020410080109000000
2015.02.26 21:58:03.731 0: HMLAN_Send: hmusb S:SC7AE9B87 stat: 00 t:00000000 d:01 r:C7AE9B87 m:26 A001 9D6EBB 29A75F 0203
2015.02.26 21:58:04.044 0: HMLAN_Parse: hmusb R:E29A75F stat:0100 t:00DE3610 d:FF r:FFBB m:26 A010 29A75F 9D6EBB 019D6EBB0200000000
2015.02.26 21:58:04.396 0: HMLAN_Parse: hmusb R:RC7AE9B87 stat:0041 t:00DE3615 d:01 r:FFBB m:26 A010 29A75F 9D6EBB 019D6EBB0200000000
2015.02.26 21:58:04.499 0: HMLAN_Send: hmusb S:SC7AE9E87 stat: 00 t:00000000 d:01 r:C7AE9E87 m:27 A001 9D6EBB 29A75F 02049D6EBB0204
2015.02.26 21:58:04.812 0: HMLAN_Parse: hmusb R:E29A75F stat:0100 t:00DE3918 d:FF r:FFC1 m:27 A010 29A75F 9D6EBB 0201800000
2015.02.26 21:58:04.829 0: HMLAN_Send: hmusb I:+29A75F,01,01,1E
2015.02.26 21:58:05.196 0: HMLAN_Parse: hmusb R:RC7AE9E87 stat:0041 t:00DE391D d:01 r:FFC1 m:27 A010 29A75F 9D6EBB 0201800000
Ich hoffe ich habe die passenden Informationen zusammengestellt. Falls ihr noch weitere Infos braucht, stelle ich diese gern zu Verfügung.
Vielen Dank für jedgliche Hinweise und Unterstützung. Diesen kleine Problem hat mich schon einiges an Zeit gekostet und irgendwie komm ich nicht über die rote Leuchte hinaus.
Sebastian
sieht doch garnicht schlecht aus.
fhem bekommt eine Antwort. AES scheint korrekt. das sollte auch im Reading angezeigt werden.
expectAES setzt du im Register des WM? dann erwartet dieser, dass der Aktor einen AES request senden wird.
schalte doch einma aesCommReq ein. Dann sollte FHEM einen AES request senden, wenn sich der Aktor meldet. Ansonsten soll FHEM nichts machen (da ist aber sachen des Operator!)
Hallo Martin,
das habe ich vergessen zu erwähnen. Der WM ist nur mit 2 Buttons der vccu gepeert und ist mit keinem Aktor verbunden. Über ihn setze ich dummy Variablen und löse diverse notifies aus. In der vccu kann ich kein aesCommReq setzen und beim hmusb scheint es diese Option auch nicht zu geben. Ich habe allerdings im WM selbst aesCommReq eingeschalten - Attribute von switch:
IODev hmusb
IOgrp vccu:hmusb
aesCommReq 1
autoReadReg 4_reqStatus
event-on-change-reading battery
expert 2_full
firmware 1.4
model HM-PB-2-WM55-2
room CUL_HM
serialNr LEQ0396191
subType pushButton
webCmd getConfig:clear msgEvents
In den Readings von switch bekomme ich auch aes Bestätigungen, aber eben nur wenn ich ein Register ändere / getconfig ausführe und dann den Anlernknopf drücke. Dann gibts einer der beiden oder beide Readings:
2015-02-28 11:14:37 aesCommToDev ok
2015-02-28 11:14:35 aesKeyNbr 02
expectAES schalte ich mit folgendem Kommando an:
set switch_usharp regSet expectAES on vccu_Btn2
Hast du oder jemand anders noch weitere Ideen?
Gruß,
Sebastian
ZitatIn der vccu kann ich kein aesCommReq setzen und beim hmusb scheint es diese Option auch nicht zu geben.
klar. wäre auch inkorrekt. man setzt es je device. Also beim WM55. wenn dieser einen trigger an FHEM ( an die vccu in diesem Fall) sendet wird fhem einen AES-request senden.
das IO wird über CUL_HM in den entsprechenden mode gebracht. (nur HMLAN, HMUSB)
Okay. Wie ich das verstehe, muss eigentlich nur das sign Register im WM55 auf on und das aesCommReq Attribut auf 1 gesetzt werden. Dann sollte die vccu bei einem Trigger vom WM55, den hmusb anweisen einen AES Request zu senden. Dieser wird vom WM55 bestätigt und an den hmusb zurückgesendet, der daraufhin den Trigger verifiziert.
Allerdings scheint dies nicht zu klappen, da trotz SIGN und aesComReq im WM55, bei einem Trigger irgendwie keine AES Verifizierung stattzufinden scheint. Die grüne Bestätigung am WM55 kommt dafür viel zu früh - praktisch innerhalb von einer halben Sekunde nach loslassen des Tasters am WM55.
Das expectAES scheint ja nur eine einseitige Sache zu sein, wo man den WM55 in forcieren kann auf den AES Request zu warten, was aber keinen Einfluß auf die Abwicklung in der vccu / hmusb zu sein scheint.
Die Frage sein also zu sein, warum sendet das hmusb keinen AES Request, oder warum wird dieser vom WM55 nicht erkannt? Gibts da eine Möglichkeit herauszufinden was da schiefläuft?
Sebastian
ZitatOkay. Wie ich das verstehe, muss eigentlich nur das sign Register im WM55 auf on und das aesCommReq Attribut auf 1 gesetzt werden
nein.
ein device, welches einen trigger empfängt oder eine Abfrage beantworten soll muss sich versichern, dass die Quelle authentisch ist.
In deinem Fall sendet der WM an die VCCU. Also muss die VCCU den AES request anstossen. Anders rum kann es nicht funktioniern.
sign einschalten bedeutet, dass der WM bei einer Anfrage (register setzen, peeren,...) sich versichern muss, dass die Quelle autorisiert ist.
Zitatas expectAES scheint ja nur eine einseitige Sache zu sein, wo man den WM55 in forcieren kann auf den AES Request zu warten, was aber keinen Einfluß auf die Abwicklung in der vccu / hmusb zu sein scheint.
ist in Wiki erklärt. es kommt der trigger, der empfänger stellt eine AES-frage, der sender muss antworten, der empfänger quittiert. Wer welche Rolle spielt hängt vom Kommando ab.
ZitatDie Frage sein also zu sein, warum sendet das hmusb keinen AES Request, oder warum wird dieser vom WM55 nicht erkannt?
schicke einmal einen Log, wenn alles eingeschaltet ist. Die vom HMLAN gesendeten AES message sieht man im Log nicht... muss man den Status auswerten. daher ist einLog erforderlich
Hallo Martin,
ich hab wie hier (http://www.fhemwiki.de/wiki/Homematic_Nachrichten_sniffen) beschrieben das logIds "all,sys" Attribut gesetzt und gleichzeitig auch verbose auf 3, damit man die Kommandos im Log auch sieht.
Dann hab ich expectAES für beide Kanäle am WM55 eingeschaltet und beide Tasten betätigt. Danach hab ich expectAES wieder abgeschaltet.
Anbei das Log.
Ich hoffe das ist was du brauchst. Falls nicht, was müsste ich noch umstellen um ein ausführlicheres Log zu bekommen? Ich konnte außer der Nachrichten sniffen Wiki Seite nichts anderes finden.
Einen schönen Abend noch,
Sebastian
das log scheint keinen Fehler zu haben.
ich sehe keinen tastendruck. es kommt immer ein "anlernen".
ich hatte verstanden, dass das Problem beim normalen Tastendruck vorliegt.
du hast sicher die aktuelle SW - CUL_HM und HMConfig. Sonst klappt es nicht.
Die Tastendrücke habe ich im Log mit einer ## Zeile markiert. Hier die Zeilen aus dem Log, welche zeitlich zu meinen Tastendrücken passen sollten:
## "switch_sharp" Button gedrückt (mit vccu_Btn1 verknüpft)
2015.02.28 19:48:45.854 0: HMLAN_Send: hmusb I:K
2015.02.28 19:48:45.914 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110916 d:26354C O:9D6EBB t:0AB48BB2 IDcnt:0008
2015.02.28 19:49:10.858 0: HMLAN_Send: hmusb I:K
2015.02.28 19:49:10.906 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110916 d:26354C O:9D6EBB t:0AB4ED52 IDcnt:0008
2015.02.28 19:49:13.918 0: HMLAN_Parse: hmusb R:E29A75F stat:0000 t:0AB4F90F d:FF r:FFC1 m:CF A640 29A75F 9D6EBB 0128
2015.02.28 19:49:14.168 0: HMLAN_Parse: hmusb R:E29A75F stat:0000 t:0AB4FA0F d:FF r:FFC3 m:D0 A240 29A75F 9D6EBB 0128
2015.02.28 19:49:14.426 0: HMLAN_Parse: hmusb R:E29A75F stat:0000 t:0AB4FB0E d:FF r:FFC2 m:D1 A240 29A75F 9D6EBB 0128
## "switch_usharp" Button gedrückt (mit vccu_Btn2 verknüpft)
2015.02.28 19:49:34.810 0: HMLAN_Parse: hmusb R:E29A75F stat:0000 t:0AB54AA8 d:FF r:FFC1 m:D2 A640 29A75F 9D6EBB 02A3
2015.02.28 19:49:35.064 0: HMLAN_Parse: hmusb R:E29A75F stat:0000 t:0AB54BA7 d:FF r:FFC2 m:D3 A240 29A75F 9D6EBB 02A3
2015.02.28 19:49:35.322 0: HMLAN_Parse: hmusb R:E29A75F stat:0000 t:0AB54CA7 d:FF r:FFC2 m:D4 A240 29A75F 9D6EBB 02A3
2015.02.28 19:49:35.861 0: HMLAN_Send: hmusb I:K
2015.02.28 19:49:35.898 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110916 d:26354C O:9D6EBB t:0AB54EF2 IDcnt:0008
Ich hab auch mal angehängt, was im event monitor erscheint wenn ich expectAES für beide Tasten anschalte und dann zuerst die switch_sharp und dann die switch_usharp Taste betätige.
Außer bei ändern der expectAES Einstellungen, erscheint da nichts bezüglich AES soweit ich das sehen kann.
Meine CUL_HM Version:
10_CUL_HM.pm 7913 2015-02-08 10:13:05Z
und die HMConfig:
$Id: HMConfig.pm 7912 2015-02-08 08:46:27Z
Sebastian
EDIT:
Ich hab gerade geupdated und nutze nun:
# $Id: 10_CUL_HM.pm 8070 2015-02-22 16:10:26Z
# $Id: HMConfig.pm 8070 2015-02-22 16:10:26Z
Soweit ich das einschätzen kann, hat sich nichts geändert. Hier nochmal ein Rohlog:
2015.03.01 12:07:08.428 0: HMLAN_Send: hmusb I:K
2015.03.01 12:07:08.483 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110916 d:26354C O:9D6EBB t:0E344642 IDcnt:0008
2015.03.01 12:07:08.514 0: HMLAN_Parse: hmusb R:E29A75F stat:0000 t:0E344655 d:FF r:FFBB m:F9 A640 29A75F 9D6EBB 012B
2015.03.01 12:07:08.738 0: HMLAN_Parse: hmusb R:E29A75F stat:0000 t:0E344754 d:FF r:FFBF m:FA A240 29A75F 9D6EBB 012B
2015.03.01 12:07:08.994 0: HMLAN_Parse: hmusb R:E29A75F stat:0000 t:0E344854 d:FF r:FFBF m:FB A240 29A75F 9D6EBB 012B
2015.03.01 12:07:24.099 0: HMLAN_Parse: hmusb R:E29A75F stat:0000 t:0E34834F d:FF r:FFB8 m:FC A640 29A75F 9D6EBB 02AD
2015.03.01 12:07:24.353 0: HMLAN_Parse: hmusb R:E29A75F stat:0000 t:0E34844F d:FF r:FFBE m:FD A240 29A75F 9D6EBB 02AD
2015.03.01 12:07:24.609 0: HMLAN_Parse: hmusb R:E29A75F stat:0000 t:0E34854F d:FF r:FFBF m:FE A240 29A75F 9D6EBB 02AD
2015.03.01 12:07:33.434 0: HMLAN_Send: hmusb I:K
2015.03.01 12:07:33.475 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110916 d:26354C O:9D6EBB t:0E34A7E1 IDcnt:0008
Zuerst habe ich den switch_sharp Knopf gedrückt, eine Weile gewartet und dann den switch_usharp Knopf gedrückt.
Auch im event monitor erscheint nichts neues bezüglich AES:
2015-03-01 12:07:24.454 CUL_HM switch_usharp trigger_cnt: 173
2015-03-01 12:07:24.454 CUL_HM switch_usharp Short (to vccu)
2015-03-01 12:07:24.454 CUL_HM switch_usharp trigger: Short_173
2015-03-01 12:07:24.458 CUL_HM vccu_Btn2 trig_switch_usharp: short
2015-03-01 12:07:24.458 CUL_HM vccu_Btn2 trigLast: switch_usharp :short
2015-03-01 12:07:24.656 CUL_HM switch battery: ok
2015-03-01 12:07:24.656 CUL_HM switch switch_usharp Short (to vccu)
2015-03-01 12:07:24.656 CUL_HM switch CMDs_done
2015-03-01 12:07:24.795 CUL_HM switch_usharp trigger_cnt: 173
2015-03-01 12:07:24.795 CUL_HM switch_usharp Short (to vccu)
2015-03-01 12:07:24.795 CUL_HM switch_usharp trigger: Short_173
2015-03-01 12:07:24.798 CUL_HM vccu_Btn2 trig_switch_usharp: short
2015-03-01 12:07:24.798 CUL_HM vccu_Btn2 trigLast: switch_usharp :short
FHEM sendet garnicht. ist etwas mit dem Button 1 oder 2 gepeert? We sollte eine VCCU mit einem entsprechenden Kanal geben.
Es fehlen auch die init-messages, die dem HMLAN sagen, dass er AES anfordern soll. hast du das abgeschnitten?
Ja, vccu_Btn1 und vccu_Btn2 sind mit den Buttons des WM55 gepeert - siehe hminfo Details aus 1. Post:
x-ref list
switch_sharp => vccu_Btn1
switch_usharp => vccu_Btn2
vccu_Btn1 => switch_sharp
vccu_Btn2 => switch_usharp
Ich hab auch nochmal versucht das peering aufzuheben und neuzusetzen, aber das hat auch nichts geändert. Peering habe ich mit:
set switch getConfig
set switch_sharp peerChan 0 vccu_Btn1 single set
set switch_usharp peerChan 0 vccu_Btn2 single set
set switch getConfig
und anschließendem Drücken der Anlerntaste vorgenommen.
Beim Rohlog habe ich nicht wissentlich etwas abgeschnitten. Hab gerad nochmal eins mitgeschnitten. Ich habe zuerst den switch_sharp betätigt und dann einige Sekunden später switch_usharp. Danach habe ich ein paar Minuten gewartet und dann dies aus dem Log kopiert:
2015.03.01 19:31:01.084 0: HMLAN_Send: hmusb I:K
2015.03.01 19:31:01.135 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110916 d:26354C O:9D6EBB t:0FCAA7E2 IDcnt:0008
2015.03.01 19:31:15.439 0: HMLAN_Parse: hmusb R:E29A75F stat:0000 t:0FCADFC3 d:FF r:FFBE m:38 A640 29A75F 9D6EBB 0130
2015.03.01 19:31:15.693 0: HMLAN_Parse: hmusb R:E29A75F stat:0000 t:0FCAE0C2 d:FF r:FFBE m:39 A240 29A75F 9D6EBB 0130
2015.03.01 19:31:15.951 0: HMLAN_Parse: hmusb R:E29A75F stat:0000 t:0FCAE1C1 d:FF r:FFBD m:3A A240 29A75F 9D6EBB 0130
2015.03.01 19:31:26.088 0: HMLAN_Send: hmusb I:K
2015.03.01 19:31:26.127 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110916 d:26354C O:9D6EBB t:0FCB0981 IDcnt:0008
2015.03.01 19:31:27.600 0: HMLAN_Parse: hmusb R:E29A75F stat:0000 t:0FCB0F3C d:FF r:FFB6 m:3B A640 29A75F 9D6EBB 02BE
2015.03.01 19:31:27.854 0: HMLAN_Parse: hmusb R:E29A75F stat:0000 t:0FCB103C d:FF r:FFBE m:3C A240 29A75F 9D6EBB 02BE
2015.03.01 19:31:28.109 0: HMLAN_Parse: hmusb R:E29A75F stat:0000 t:0FCB113B d:FF r:FFBF m:3D A240 29A75F 9D6EBB 02BE
2015.03.01 19:31:51.091 0: HMLAN_Send: hmusb I:K
2015.03.01 19:31:51.151 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110916 d:26354C O:9D6EBB t:0FCB6B41 IDcnt:0008
2015.03.01 19:32:16.096 0: HMLAN_Send: hmusb I:K
2015.03.01 19:32:16.143 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110916 d:26354C O:9D6EBB t:0FCBCCE1 IDcnt:0008
2015.03.01 19:32:41.103 0: HMLAN_Send: hmusb I:K
2015.03.01 19:32:41.167 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110916 d:26354C O:9D6EBB t:0FCC2EA0 IDcnt:0008
2015.03.01 19:33:06.113 0: HMLAN_Send: hmusb I:K
2015.03.01 19:33:06.159 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110916 d:26354C O:9D6EBB t:0FCC9040 IDcnt:0008
2015.03.01 19:33:31.123 0: HMLAN_Send: hmusb I:K
2015.03.01 19:33:31.183 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110916 d:26354C O:9D6EBB t:0FCCF200 IDcnt:0008
2015.03.01 19:33:56.143 0: HMLAN_Send: hmusb I:K
2015.03.01 19:33:56.206 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110916 d:26354C O:9D6EBB t:0FCD53C0 IDcnt:0008
Was mir noch auffällt, bei den Buttons vom WM55 steht im peerIDs Attribut nicht nur die ID von meinem vccu Button, sondern auch noch eine 0 peerID vorn dran:
peerIDs 00000000,9D6EBB01
peerIDs 00000000,9D6EBB02
In den Readings hingegen steht nur der vccu Button:
peerList vccu_Btn1,
peerList vccu_Btn2,
Ich nutze auch nicht das HMLAN, sondern das HMUSB Device.
Was ich noch geändert habe, sind die notifies, die die Buttons vom WM55 überwachen. Diese hatte ich noch auch auf die Buttons vom WM55 eingestellt, anstatt die vccu Buttons zu überwachen. Das zu ändern hat allergings auch keine Abhilfe gebracht.
Sebastian
dein HMLAN hat die ID 26354C
Werksseitig ist es die ID 9D6EBB
der WM sendet an die orginale - da ist der HMLAN taub (hast du ihm so gesagt).
du kannst einen virtuellen Kanal mit HMId 9D6EBB einrichten. Wenn du AES nutzen willst stelle den HMLAN um oder peere den WM55 mit der aktuell eingestellten ID.
Die 00000000 muss immer in den peerIDs stehen. das zeigt, dass vollständig gelesen ist (nicht manuell eintragen!)
Hallo Martin,
hm, das "list hmusb" Kommando zeigt allerdings das an:
Readings:
2015-03-01 12:01:43 D-HMIdAssigned 9D6EBB
2015-03-01 12:01:43 D-HMIdOriginal 26354C
Attributes:
hmId 9D6EBB
Demzufolge sollte die originale HMId des hmusb 26354C sein und meine aktuell zugewiesene 9D6EBB. Das deckt sich auch mit den Readings vom WM55:
Readings:
2015-03-01 19:42:52 PairedTo 0x9D6EBB
2015-02-09 18:59:40 R-pairCentral 0x9D6EBB
Die vccu ist auch darauf eingestellt:
DEF 9D6EBB
Oder lese ich da etwas falsches heraus?
Ich danke dir für deine tatkräftige Unterstützung bei meinem Problem. Auch wenn es vielleicht nicht so erscheint, bevor ich diesen Thread gestartet habe, versuchte ich dieses Problem schon mehrfach selbst zu lösen seit ich FHEM vor ein paar Monaten installiert habe. Dabei habe ich das Forum, Wiki und die Dokumentation gewälzt und die diversen Anweisungen und Vorschläge ausprobiert. Letztendlich wird es sich sicher als ein simpler Anfängerfehler herausstellen.
Viele Grüße,
Sebastian
Habe ich mich evtl vertan.
Waere noch wichtig, was fhem zum hmlan sagt... da muss aes eingeschaltet werden.
Beziehst du dich dabei auf das logIDs "all,sys" Attribut? Wenn ich einen der Buttons am WM55 drücke, gibts leider nicht mehr Einträge im Log als ich zuvor schon gepostet habe.
Oder würde es dir helfen wenn ich die Kommunikation mit einem anderen Aktor mitschneide, wo AES problemlos zu funktionieren scheint? Hier ein Logmitschnitt wenn ich meinen HM-LC-Sw1PBU-FM per Weboberfläche an und wieder ausschalte:
2015.03.03 00:29:55.229 0: HMLAN_Send: hmusb I:K
2015.03.03 00:29:55.272 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110916 d:26354C O:9D6EBB t:1602AA76 IDcnt:0008
2015.03.03 00:30:10.133 0: HMLAN_Send: hmusb S:SDCD34D9F stat: 00 t:00000000 d:01 r:DCD34D9F m:AF A011 9D6EBB 2B4E23 0201C80000
2015.03.03 00:30:10.343 0: HMLAN_Parse: hmusb R:E2B4E23 stat:0100 t:1602E54D d:FF r:FFCD m:AF A002 2B4E23 9D6EBB 04B76223406F2202
2015.03.03 00:30:10.599 0: HMLAN_Parse: hmusb R:RDCD34D9F stat:0021 t:1602E552 d:01 r:FFCC m:AF 8002 2B4E23 9D6EBB 0101C80033E544E3FA
2015.03.03 00:30:20.232 0: HMLAN_Send: hmusb I:K
2015.03.03 00:30:20.296 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110916 d:26354C O:9D6EBB t:16030C36 IDcnt:0008
2015.03.03 00:30:27.604 0: HMLAN_Send: hmusb S:SDCD391DE stat: 00 t:00000000 d:01 r:DCD391DE m:B0 A011 9D6EBB 2B4E23 0201000000
2015.03.03 00:30:27.816 0: HMLAN_Parse: hmusb R:E2B4E23 stat:0100 t:1603298D d:FF r:FFCB m:B0 A002 2B4E23 9D6EBB 0448F695A3A96902
2015.03.03 00:30:28.071 0: HMLAN_Parse: hmusb R:RDCD391DE stat:0021 t:16032992 d:01 r:FFCC m:B0 8002 2B4E23 9D6EBB 010100003443FBEC04
Falls du etwas anderes meintest, kannst du mir ein paar Details geben, wie ich an die gewünschte Info herankomme?
Sebastian
Hm ....
Die einstellmessage ist nicht zu sehen. Sollte vor der message einmal kommen. Kannst du ein list schicken?
Halt.... da wird die aes antwort gesendet. Eigentlich alles ok
Hallo Martin,
ich habe ein vollständiges list der beteiligten Komponenten angehängt.
Vom WM55 habe ich auch den Namen von switch to switchm geändert, da ich gesehen hatte, dass bei meinen Sw1PBU-FM's das subType Attribut auch switch heisst und daher in der Weboberfläche mit meinem WM55 verlinkt war. Die Namensänderung hat aber keine Abhilfe gebracht.
Viele Grüße,
Sebastian
Hi Martin,
während des getConfigs scheint es ja zwischen WM55 und hmUSB mit dem AES zu klappen. Es scheint also nur im regulären Betrieb ein Problem mit dem AES zu geben.
Gibt es denn keine weitere Möglichkeit dem Problem auf den Grund zu gehen?
Der WM55 ist in meinem System ein zentrales Element und ohne AES bei dem Schalter, könnte ich praktisch auch AES überall sonst abstellen, da man über den WM55 mein bescheidenes Alarmsystem aushebeln könnte. AES war auch eins der auschlaggebenden Faktoren, warum ich mich für Homematic entschieden habe. Bis auf den WM55 läuft es ja auch wunderbar.
Ich hoffe, dass du vielleicht noch ein paar Ideen und Hinweise hast.
Viele Grüße,
Sebastian
Hi,
habe es einmal probiert. Bei mir sieht es so aus:
wenn attr aes communikation eingeschaltet ist und der WM eine trigger sendet wir dieser vom HMLAN geprüft. es wird im Device aesCommToDev als ok gesetzt.
HMLAN(FHEM) sendet dann sie parameter (unabhängig von der AES response).
Was in FHEM fehlt ist eine bessere/einfachere Kopplung von AES zu den triggern. da werde ich wohl etwas machen müssen.
Was ich nicht sehen kann:
WM55 fordert beim Empfang der Informationen keine Zertifizierung an. Das Betrifft nicht die Configuration, nur die Informationen.
Wo genau brauchst du eine Sicherung?
Hi Martin,
hast du auch einen WM55? Welche Firmware hat dein Schalter? Ich frage mich gerade ob mein Gerät vielleicht eine neuere Firmware hat und es daher vielleicht zu meinem Problem kommt? Im Wiki für den WM55 ist noch von Firmware 1.1 die Rede. Meiner hat allerdings Version 1.4.
Was ich so in den anderen Threads gelesen habe, scheint HMLAN doch schon eine gute Möglichkeit zu haben, via "trig_aes" ein notify einzurichten, dass nur ausgeführt wird wenn die AES Signatur stimmt. Das klappt bei mir allerdings noch nicht, da trotz eingeschaltetem aesCommReq am WM55 vom HMLAN irgendwie keine AES Anfrage gestellt wird und es daher keinen trig_aes Event gibt, den ich auswerten kann.
Der Schwachpunkt in meiner Installation sind die 2 Buttons vom VCCU, die mit dem WM55 gepeered sind. Über diese lässt sich die Anlage scharf / inaktiv schalten. Das sollte allergings kein Problem sein, wenn ich die trig_aes Events nutzen könnte.
Folgende Einträge habe ich
define switchm CUL_HM 29A75F
attr switchm IODev hmusb
attr switchm IOgrp vccu:hmusb
attr switchm aesCommReq 1
attr switchm autoReadReg 4_reqStatus
attr switchm event-on-change-reading battery
attr switchm expert 2_full
attr switchm firmware 1.4
attr switchm model HM-PB-2-WM55-2
attr switchm room CUL_HM
attr switchm serialNr LEQ0396191
attr switchm subType pushButton
attr switchm webCmd getConfig:clear msgEvents
define switchm_sharp CUL_HM 29A75F01
attr switchm_sharp model HM-PB-2-WM55-2
attr switchm_sharp peerIDs 00000000,9D6EBB01,
define switchm_usharp CUL_HM 29A75F02
attr switchm_usharp model HM-PB-2-WM55-2
attr switchm_usharp peerIDs 00000000,9D6EBB02,
Fehlt da vielleicht ein entscheidendes Attribut?
Beim Testen nehme ich auch immer das event-on-change-reading raus und eben habe ich es nochmal mit einem "event-on-update-reading .*" probiert, damit auch kein Event vom WM55 gefiltert wird, aber es brachte keine Besserung.
Ich wünsche einen schönen Sonntag,
Sebastian
Sebastian
mein WM55 hat FW 1.0
"trig_aes" wird im "peer" gesetzt. Wenn der Button also nicht gepeert ist gibt es keinen peer udn somit kein trig_aes.
das ist evtl nicht optimal.
Immer kommen sollte im Device ein aesCommToDev.
habe noch einen trigger eingebaut. Es war auch noch ein Problem an dieser Stelle mit dem triggern. V8221 sollte besser gehen
Guten Abend Martin,
ein Firmwareupdate für den WM55 scheint es zumindest für den WM55 nicht zu geben, gibts wohl dann vielleicht sogar unterschiedliche Hardwarerevisionen.
Die Buttons am WM55 habe ich mit virtuellen Buttons an der VCCU gepeert. Sollte das dann nicht ähnlich funktionieren, wie wenn der WM55 mit einem Aktor gepeert ist?
Ich hab gerade ein FHEM Update durchgeführt und danach manuell (während FHEM heruntergefahren war) dein V8221 und V8222 commit. Nachdem ich FHEM wieder gestartet hatte, scheint das Problem unverändert zu bestehen.
Hier ein rawlog wobei ich wieder zuerst einen und dann den anderen Button am WM55 betätigt habe. Beides wurde mit der roten Led quittiert.
2015.03.15 20:22:20.352 0: HMLAN_Parse: hmusb R:E2C1904 stat:0000 t:5812A52C d:FF r:FFC3 m:F5 A610 2C1904 9D6EBB 06010000
2015.03.15 20:22:23.285 0: HMLAN_Send: hmusb I:K
2015.03.15 20:22:23.328 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110916 d:26354C O:9D6EBB t:5812B0CD IDcnt:0008
2015.03.15 20:22:37.185 0: HMLAN_Parse: hmusb R:E29A75F stat:0000 t:5812E6EB d:FF r:FFB8 m:3A A640 29A75F 9D6EBB 02FD
2015.03.15 20:22:37.439 0: HMLAN_Parse: hmusb R:E29A75F stat:0000 t:5812E7EA d:FF r:FFBA m:3B A240 29A75F 9D6EBB 02FD
2015.03.15 20:22:37.696 0: HMLAN_Parse: hmusb R:E29A75F stat:0000 t:5812E8EA d:FF r:FFBB m:3C A240 29A75F 9D6EBB 02FD
2015.03.15 20:22:48.288 0: HMLAN_Send: hmusb I:K
2015.03.15 20:22:48.352 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110916 d:26354C O:9D6EBB t:5813128D IDcnt:0008
2015.03.15 20:23:12.992 0: HMLAN_Parse: hmusb R:E29A75F stat:0000 t:581372D1 d:FF r:FFBA m:3D A640 29A75F 9D6EBB 0157
2015.03.15 20:23:13.248 0: HMLAN_Parse: hmusb R:E29A75F stat:0000 t:581373D1 d:FF r:FFBB m:3E A240 29A75F 9D6EBB 0157
2015.03.15 20:23:13.359 0: HMLAN_Send: hmusb I:K
2015.03.15 20:23:13.408 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110916 d:26354C O:9D6EBB t:5813746D IDcnt:0008
2015.03.15 20:23:13.504 0: HMLAN_Parse: hmusb R:E29A75F stat:0000 t:581374D1 d:FF r:FFBB m:3F A240 29A75F 9D6EBB 0157
2015.03.15 20:23:38.373 0: HMLAN_Send: hmusb I:K
2015.03.15 20:23:38.431 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110916 d:26354C O:9D6EBB t:5813D62C IDcnt:0008
Im Eventmonitor ist auch wieder keinerlei AES Austausch zu erkennen:
2015-03-15 20:22:37.244 CUL_HM switchm battery: ok
2015-03-15 20:22:37.244 CUL_HM switchm CMDs_done
2015-03-15 20:22:37.244 CUL_HM switchm switchm_usharp Short (to vccu)
2015-03-15 20:22:37.273 CUL_HM switchm_usharp Short (to vccu)
2015-03-15 20:22:37.273 CUL_HM switchm_usharp trigger: Short_253
2015-03-15 20:22:37.273 CUL_HM switchm_usharp trigger_cnt: 253
2015-03-15 20:22:37.371 CUL_HM vccu_Btn2 trigLast: switchm_usharp :short
2015-03-15 20:22:37.371 CUL_HM vccu_Btn2 trig_switchm_usharp: short
2015-03-15 20:22:37.446 CUL_HM switchm battery: ok
2015-03-15 20:22:37.446 CUL_HM switchm CMDs_done
2015-03-15 20:22:37.446 CUL_HM switchm switchm_usharp Short (to vccu)
2015-03-15 20:22:37.451 CUL_HM switchm_usharp Short (to vccu)
2015-03-15 20:22:37.451 CUL_HM switchm_usharp trigger: Short_253
2015-03-15 20:22:37.451 CUL_HM switchm_usharp trigger_cnt: 253
2015-03-15 20:22:37.521 CUL_HM vccu_Btn2 trigLast: switchm_usharp :short
2015-03-15 20:22:37.521 CUL_HM vccu_Btn2 trig_switchm_usharp: short
2015-03-15 20:22:37.738 CUL_HM switchm battery: ok
2015-03-15 20:22:37.738 CUL_HM switchm CMDs_done
2015-03-15 20:22:37.738 CUL_HM switchm switchm_usharp Short (to vccu)
2015-03-15 20:22:37.767 CUL_HM switchm_usharp Short (to vccu)
2015-03-15 20:22:37.767 CUL_HM switchm_usharp trigger: Short_253
2015-03-15 20:22:37.767 CUL_HM switchm_usharp trigger_cnt: 253
2015-03-15 20:22:37.870 CUL_HM vccu_Btn2 trigLast: switchm_usharp :short
2015-03-15 20:22:37.870 CUL_HM vccu_Btn2 trig_switchm_usharp: short
2015-03-15 20:23:13.048 CUL_HM switchm battery: ok
2015-03-15 20:23:13.048 CUL_HM switchm CMDs_done
2015-03-15 20:23:13.048 CUL_HM switchm switchm_sharp Short (to vccu)
2015-03-15 20:23:13.077 CUL_HM switchm_sharp Short (to vccu)
2015-03-15 20:23:13.077 CUL_HM switchm_sharp trigger: Short_87
2015-03-15 20:23:13.077 CUL_HM switchm_sharp trigger_cnt: 87
2015-03-15 20:23:13.119 CUL_HM vccu_Btn1 trigLast: switchm_sharp :short
2015-03-15 20:23:13.119 CUL_HM vccu_Btn1 trig_switchm_sharp: short
2015-03-15 20:23:13.297 CUL_HM switchm battery: ok
2015-03-15 20:23:13.297 CUL_HM switchm CMDs_done
2015-03-15 20:23:13.297 CUL_HM switchm switchm_sharp Short (to vccu)
2015-03-15 20:23:13.325 CUL_HM switchm_sharp Short (to vccu)
2015-03-15 20:23:13.325 CUL_HM switchm_sharp trigger: Short_87
2015-03-15 20:23:13.325 CUL_HM switchm_sharp trigger_cnt: 87
2015-03-15 20:23:13.356 CUL_HM vccu_Btn1 trigLast: switchm_sharp :short
2015-03-15 20:23:13.356 CUL_HM vccu_Btn1 trig_switchm_sharp: short
2015-03-15 20:23:13.553 CUL_HM switchm battery: ok
2015-03-15 20:23:13.553 CUL_HM switchm CMDs_done
2015-03-15 20:23:13.553 CUL_HM switchm switchm_sharp Short (to vccu)
2015-03-15 20:23:13.581 CUL_HM switchm_sharp Short (to vccu)
2015-03-15 20:23:13.581 CUL_HM switchm_sharp trigger: Short_87
2015-03-15 20:23:13.581 CUL_HM switchm_sharp trigger_cnt: 87
2015-03-15 20:23:13.612 CUL_HM vccu_Btn1 trigLast: switchm_sharp :short
2015-03-15 20:23:13.612 CUL_HM vccu_Btn1 trig_switchm_sharp: short
Kann es sein, dass ich irgendwas in der VCCU nicht richtig eingerichtet habe?
Mein HM-CFG-USB hat übrigens die Firmware 0.967 wie sie hier für hmland (http://forum.fhem.de/index.php/topic,13071.0.html) verlinkt wurde.
Sebastian
Habe leider keine Lösung aber das gleiche Problem.
HM-CFG-USB2 via Software zum HMLAN gemacht und in FHEM integriert. Die beiden Channels des WM55 an die Channels der vCCU gepeert. Drücke ich jetzt die Tasten wird mir grün signalisiert das alles ok ist. Aktiviere ich expectAES in den Channels des WM55 bleibt es leider rot. aesCommReq kann ich bei vCCU nicht setzen da es ein virtuelles Device ist.
Ähnliches Problem habe ich mit meiner Fernbedienung HM-RC-4-2.
Kann es sein dass es mit dem HM-CFG-USB2 nicht funktioniert?
Ich kann nicht sehen, wie aes eingeschaltet wird.
Logge wenn du das attr aescom setzt und dann die aktion danach
Kann es sein dass es die falsche id ist zu der der wm55 sendet ?
aescomreq müsste ich ja am empfangenden Gerät einstellen. Das wäre ja die virtuelle CCU und bei der darf ich per Web Frontend das Attribut nicht setzen.
USB Stick
####################################
### HMLAN
define hmusb HMLAN 127.0.0.1:1234
attr hmusb hmId 2634DA
attr hmusb hmKey 01:#######
attr hmusb hmLanQlen 1_min
attr hmusb room hidden
D-HMIdAssigned
2634DA
2015-03-19 19:32:24
D-HMIdOriginal
2634DA
2015-03-19 19:32:24
vCCU
####################################
### vCCU
define vCCU CUL_HM 2634DA
attr vCCU IODev hmusb
attr vCCU expert 2_full
attr vCCU model CCU-FHEM
attr vCCU room hidden
attr vCCU subType virtual
attr vCCU webCmd virtual:update
WM55
define SZ.HM_PB_2_WM55_2 CUL_HM 2A6EFC
attr SZ.HM_PB_2_WM55_2 IODev hmusb
attr SZ.HM_PB_2_WM55_2 aesCommReq 1
attr SZ.HM_PB_2_WM55_2 autoReadReg 4_reqStatus
attr SZ.HM_PB_2_WM55_2 expert 2_full
attr SZ.HM_PB_2_WM55_2 firmware 1.4
attr SZ.HM_PB_2_WM55_2 model HM-PB-2-WM55-2
attr SZ.HM_PB_2_WM55_2 room CUL_HM
attr SZ.HM_PB_2_WM55_2 serialNr LTK0019019
attr SZ.HM_PB_2_WM55_2 subType pushButton
attr SZ.HM_PB_2_WM55_2 webCmd getConfig:clear msgEvents
define SZ.Btn_1 CUL_HM 2A6EFC01
attr SZ.Btn_1 model HM-PB-2-WM55-2
attr SZ.Btn_1 peerIDs 00000000,2634DA05,
attr SZ.Btn_1 room Schlafzimmer
define SZ.Btn_2 CUL_HM 2A6EFC02
attr SZ.Btn_2 model HM-PB-2-WM55-2
attr SZ.Btn_2 peerIDs 00000000,2634DA06,
attr SZ.Btn_2 room Schlafzimmer
vCCU Channel
define vCCU_Btn5 CUL_HM 2634DA05
attr vCCU_Btn5 model CCU-FHEM
attr vCCU_Btn5 peerIDs 2A6EFC01,
attr vCCU_Btn5 room hidden
attr vCCU_Btn5 webCmd press short:press long
define vCCU_Btn6 CUL_HM 2634DA06
attr vCCU_Btn6 model CCU-FHEM
attr vCCU_Btn6 peerIDs 2A6EFC02,
attr vCCU_Btn6 room hidden
attr vCCU_Btn6 webCmd press short:press long
Zitataescomreq müsste ich ja am empfangenden Gerät einstellen. Das wäre ja die virtuelle CCU und bei der darf ich per Web Frontend das Attribut nicht setzen.
falsch - macht auch keinen Sinn.
du stellst es bei allen devices ein, von denen du (FHEM) eine signatur verlangt.
Das andere würde nicht funktionieren - es ist ein register. Du musst es ja INS device schreiben (das sind dann immer Register) damit das Device von JEDEN sender eine signatur verlangt.
Es ist im Device je channel einstellbar - und auch für das Device selbst.
Hi Martin,
in letzter Zeit habe ich nicht viel mit FHEM gebastelt, aber das Problem mit meinem WM55 und AES besteht immernoch. Ich würde dies gern beheben.
Gibt es noch weitere Möglichkeiten für mich weitere Details für dich zu sammeln, die dir eventuell heflen können das Problem zu lokalisieren?
@Oberlon: Im Post 23 (http://forum.fhem.de/index.php/topic,34416.msg275962.html#msg275962) bezog Martin sich glaub ich auf das Rohlog - schalte das temporär mal ein (siehe Wiki zum Homematic sniffen (http://www.fhemwiki.de/wiki/Homematic_Nachrichten_sniffen)), setze danach aescommreq im WM55 und betätige den Taster. Danach solltest du in deinem Log die Rohdaten haben, welche du posten kannst.
Ich wünsche ein schönes Wochenende,
Sebastian