kein AES mit PB-2-WM55-2 an VCCU

Begonnen von Basti, 26 Februar 2015, 22:30:18

Vorheriges Thema - Nächstes Thema

Basti

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, thread 2, thread 3, 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

martinp876

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!)

Basti

#2
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

martinp876

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)

Basti

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

martinp876

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

Basti

Hallo Martin,
ich hab wie hier 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

martinp876

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.

Basti

#8
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

martinp876

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?

Basti

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

martinp876

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!)

Basti

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

martinp876

Habe ich mich evtl vertan.
Waere noch wichtig, was fhem zum hmlan sagt... da muss aes eingeschaltet werden.

Basti

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