VCCU auf stackable CUL

Klinki · 18 März 2016, 17:42:34

Hi,

Ich gebe auf. Nach etlichen Stunden Probiererei und Foren-Suche, fällt mir nix mehr ein. Ich kriege es einfach nicht hin, ein HM-Device sauber an meine VCCU zu pairen. Es funktionierte eigentiich alles prima. Ich wollte jetzt aber einige HM-Devices auf AES-Signierung umstellen. Dazu habe ich die VCCU eingerichtet. Es klappt aber nicht, die Devices sauber an die vccu zu koppeln.
Auch sollte unter dem CUL ja eigentlich die VCCU als owner auftauchen. Tut sie aber nicht.
Hier die Definitionen des IO-Devices myCOC. Es ist ein stackable-Board von Busware. Daher auch die Konfiguration der anderen Platine (SlowRF).

Code Auswählen


define myCUL CUL /dev/ttyAMA0@38400 1234
attr myCUL rfmode SlowRF
attr myCUL room Hilfsmodule

define myCOC STACKABLE_CC myCUL
attr myCOC hmId 123456
attr myCOC rfmode HomeMatic
attr myCOC room Hilfsmodule

define vccu CUL_HM 123456
attr vccu IODev myCOC
attr vccu IOList myCOC
attr vccu hmKey 01:5bc85af58437921d673541f19ba020af
attr vccu model CCU-FHEM
attr vccu room Hilfsmodule
attr vccu subType virtual
attr vccu webCmd virtual:update

hier das List der VCCU

Code Auswählen


Internals: 
   DEF        123456 
   IODev      myCOC 
   NAME       vccu 
   NR         51 
   STATE      myCOC:ok, 
   TYPE       CUL_HM 
   assignedIOs myCOC 
   channel_01 vccu_Btn1 
   channel_02 vccu_Btn2 
   channel_03 vccu_Btn3 
   channel_04 vccu_Btn4 
   channel_05 vccu_Btn5 
   channel_06 vccu_Btn6 
   channel_07 vccu_Btn7 
   channel_08 vccu_Btn8 
   channel_09 vccu_Btn9 
   channel_0A vccu_Btn10 
   Helper: 
     Dblog: 
       State: 
         Logdb: 
           TIME       1458318025.03859 
           VALUE      myCOC:ok, 
   Readings: 
     2016-03-18 17:20:25   state           myCOC:ok, 
   Helper: 
     HM_CMDNR   1 
     mId        FFF0 
     rxType     1 
     Expert: 
       def        1 
       det        0 
       raw        0 
       tpl        0 
     Io: 
       prefIO 
       vccu 
       ioList: 
         myCOC 
     Mrssi: 
       mNo 
     Prt: 
       bErr       0 
       sProc      0 
       Rspwait: 
     Q: 
       qReqConf 
       qReqStat 
     Role: 
       dev        1 
       vrt        1 
Attributes: 
   IODev      myCOC 
   IOList     myCOC 
   hmKey      01:5bc85af58437921d673541f19ba020af 
   model      CCU-FHEM 
   room       Hilfsmodule 
   subType    virtual 
   webCmd     virtual:update

und das List der IO-Schnittstelle myCOC

Code Auswählen


Internals: 
   CMDS       mbCFiAZOGMKbRTVWXefltux 
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC: 
   DEF        myCUL 
   IODev      myCUL 
   NAME       myCOC 
   NOTIFYDEV  myCUL 
   NR         49 
   NTFY_ORDER 50-myCOC 
   PARTIAL 
   RAWMSG     A143E845E34232800000080D111000000000008E3FE31 
   RSSI       -49.5 
   STATE      Initialized 
   StackLevel 1 
   TYPE       STACKABLE_CC 
   VERSION    V 1.65 CSM868 
   initString X21 
Ar 
   myCOC_MSGCNT 23 
   myCOC_TIME 2016-03-18 17:34:33 
   Matchlist: 
     1:CUL_HM   ^A.................... 
     8:HMS      ^810e04....(1|5|9).a001 
     D:CUL_IR   ^I............ 
     H:STACKABLE_CC ^\* 
   Readings: 
     2016-03-18 17:20:14   cmds             m b C F i A Z O G M K b R T V W X e f l t u x 
     2016-03-18 17:34:33   state           Initialized 
Attributes: 
   hmId       123456 
   rfmode     HomeMatic 
   room       Hilfsmodule

Nach dem Anlernen tauchen die HM-Geräte zwar auf, mit Seriennummer usw., aber immer mit PairedTo 0x00000.

Code Auswählen

PairedTo
0x000000
2016-03-18 17:21:11
R-cyclicInfoMsg
on
2016-03-18 17:21:11
R-eventDlyTime
0 s
2016-03-18 17:21:11
R-pairCentral
0x000000

Das Einzige was mir noch einfallen würde, ist die Interfaces Homematic und FS20 zu tauschen.

Vielleicht kann mich aber von euch Pros aber mit der Nase auf meinen Fehler stoßen.

Grüße & schönes Wochenende
klinki

frank · 18 März 2016, 18:06:12

wenn vor der vccu alles gepaired war, muss man nicht nochmal pairen. einmal gepaired, immer gepaired, ausser nach reset. entscheidend ist die id der zentrale. diese muss im def der vccu definiert werden.
ausserdem in jedem device zusätzlich das attr IOgrp setzen.

poste mal ein "list <device_name>" von einem device.

Klinki · 18 März 2016, 18:36:30

Hi Frank,

Ja, das mit der ID und allesandereegal habe ich genau so verstanden. Hatte nach der Einrichtung der vccu auch gehofft nicht neu pairen zu müssen.
Hatte bei allen HMlern das IOgrp als Attribut hinzugefügt.

Bei diesem Device hab ich dennoch einen Reset gemacht.

Code Auswählen

Internals: 
   CFGFN 
   DEF        37ADD4 
   IODev      myCOC 
   LASTInputDev myCOC 
   MSGCNT     6 
   NAME       HM_37ADD4 
   NR         912 
   STATE      closed 
   TYPE       CUL_HM 
   lastMsg    No:07 - t:10 s:37ADD4 d:000000 06010000 
   myCOC_MSGCNT 6 
   myCOC_RAWMSG A0D07861037ADD400000006010000::-75.5:myCOC 
   myCOC_RSSI -75.5 
   myCOC_TIME 2016-03-18 18:11:18 
   protLastRcv 2016-03-18 18:11:18 
   protSnd    6 last_at:2016-03-18 17:21:12 
   protState  CMDs_done 
   rssi_at_myCOC avg:-72.58 min:-78 max:-66 lst:-75.5 cnt:6 
   Helper: 
     Dblog: 
       Activity: 
         Logdb: 
           TIME       1458318071.33993 
           VALUE      alive 
       D-firmware: 
         Logdb: 
           TIME       1458318071.33993 
           VALUE      1.0 
       D-serialnr: 
         Logdb: 
           TIME       1458318071.33993 
           VALUE      MEQ0287069 
       R-cyclicinfomsg: 
         Logdb: 
           TIME       1458318071.64436 
           VALUE      on 
       R-eventdlytime: 
         Logdb: 
           TIME       1458318071.87714 
           VALUE      0 s 
       R-paircentral: 
         Logdb: 
           TIME       1458318071.64436 
           VALUE      0x000000 
       R-sabotagemsg: 
         Logdb: 
           TIME       1458318071.64436 
           VALUE      on 
       R-sign: 
         Logdb: 
           TIME       1458318071.87714 
           VALUE      on 
       Alive: 
         Logdb: 
           TIME       1458321078.33418 
           VALUE      yes 
       Battery: 
         Logdb: 
           TIME       1458321078.33418 
           VALUE      ok 
       Contact: 
         Logdb: 
           TIME       1458321078.33418 
           VALUE      closed (to broadcast) 
       Sabotageerror: 
         Logdb: 
           TIME       1458321078.33418 
           VALUE      off 
       State: 
         Logdb: 
           TIME       1458321078.33418 
           VALUE      closed 
   Readings: 
     2016-03-18 17:21:11   Activity        alive 
     2016-03-18 17:21:11   D-firmware      1.0 
     2016-03-18 17:21:11   D-serialNr      MEQ0287069 
     2016-03-18 17:21:11   PairedTo        0x000000 
     2016-03-18 17:21:11   R-cyclicInfoMsg on 
     2016-03-18 17:21:11   R-eventDlyTime  0 s 
     2016-03-18 17:21:11   R-pairCentral   0x000000 
     2016-03-18 17:21:11   R-sabotageMsg   on 
     2016-03-18 17:21:11   R-sign          on 
     2016-03-18 17:21:11   RegL_00.          02:00 09:01 0A:00 0B:00 0C:00 10:01 14:06 00:00 
     2016-03-18 17:21:11   RegL_01.          08:01 20:9C 21:00 30:06 00:00 
     2016-03-18 18:11:18   alive           yes 
     2016-03-18 18:11:18   battery         ok 
     2016-03-18 18:11:18   contact         closed (to broadcast) 
     2016-03-18 18:11:18   recentStateType info 
     2016-03-18 18:11:18   sabotageError   off 
     2016-03-18 18:11:18   state           closed 
   Helper: 
     HM_CMDNR   7 
     cSnd       01F0815F37ADD401040000000001,01F0815F37ADD40103 
     mId        00C7 
     peerIDsRaw ,00000000 
     rxType     28 
     Expert: 
       def        1 
       det        0 
       raw        1 
       tpl        0 
     Io: 
       newChn     +37ADD4,00,00,00 
       nextSend   1458321078.4205 
       rxt        2 
       vccu       vccu 
       p: 
         37ADD4 
         00 
         00 
         00 
     Mrssi: 
       mNo        07 
       Io: 
         myCOC      -73.5 
     Prt: 
       bErr       0 
       sProc      0 
       Rspwait: 
     Q: 
       qReqConf 
       qReqStat 
     Role: 
       chn        1 
       dev        1 
     Rssi: 
       At_mycoc: 
         avg        -72.5833333333333 
         cnt        6 
         lst        -75.5 
         max        -66 
         min        -78 
     Shadowreg: 
Attributes: 
   IODev      myCOC 
   IOgrp      vccu 
   actCycle   000:50 
   actStatus  alive 
   autoReadReg 4_reqStatus 
   expert     2_raw 
   firmware   1.0 
   model      HM-SEC-SCo 
   peerIDs    00000000, 
   room       CUL_HM 
   serialNr   MEQ0287069 
   subType    threeStateSensor

frank · 18 März 2016, 19:04:50

das rijindal perl modul ist installiert?
sniffe die messages beim pairen, wie im wiki homematic sniffen beschrieben.

Klinki · 19 März 2016, 07:17:40

modul ist installiert. HMkey kann erstellt und zur vccu gespeichert werden.
Allerdings sagt fhem beim Versuch eine Verbindung zu signieren, dass vccu einen hmkey braucht.

aber signieren will ich im ersten Schritt auch noch nicht. Sicher, HM Sec
Geräte signieren immer, aber das unvollständige Pairing hab ich bei vccu mit allen hm Geräten.

Sniffing folgt....

frank · 19 März 2016, 10:13:12

signiert wird nur, wenn es eingeschaltet ist. beim fensteerkontakt ist es per default an, sign=on.

probier mal die fw aus dem angepinnten thread.

Klinki · 19 März 2016, 11:18:59

Wie soll ich signieren ausschalten, wenn ich nicht sauber pairen kann?
Es bleibt halt auf "r-sign set_off"

Firmware aus angepinntem Thread? Du meinst aus https://forum.fhem.de/index.php/topic,31421.0.html?

Werde ich mal versuchen.

frank · 19 März 2016, 13:25:49

ja, diese fw.
sniffen ist nicht schwer. einfach 3 attribute setzen.

Klinki · 19 März 2016, 15:39:56

Yo. Is nicht schwer. Nur nicht mehr ganz so wichtig wenn Dein Verein gerade spielt

2:0 gewonnen....geht weiter...
also:

Code Auswählen

2016.03.19 15:28:51.930 3: CUL_HM set vccu hmPairForSec 3600
2016.03.19 15:28:58.627 4: CUL_Parse: myCOC A 14 C2 A45F 3420D6 123456 839284006C4204E708DFFE1E -59
2016.03.19 15:28:58.898 4: CUL_Parse: myCOC A 1A 00 8400 39776C 000000 1200A54D455130303736393731400400001D -59.5
2016.03.19 15:28:59.118 4: CUL_Parse: myCOC A 16 01 A010 39776C 123456 0202000A000B000C00180000001B -60.5
2016.03.19 15:28:59.347 4: CUL_Parse: myCOC A 12 02 A010 39776C 123456 0204100800090000001E -59
2016.03.19 15:28:59.568 4: CUL_Parse: myCOC A 0E 03 A010 39776C 123456 01000000001D -59.5
2016.03.19 15:28:59.796 4: CUL_Parse: myCOC A 12 04 A010 39776C 123456 0204100800090000001B -60.5
2016.03.19 15:29:00.017 4: CUL_Parse: myCOC A 0E 05 A010 39776C 123456 010000000023 -56.5
2016.03.19 15:29:00.245 4: CUL_Parse: myCOC A 12 06 A010 39776C 123456 02041008000900000024 -56
2016.03.19 15:29:00.466 4: CUL_Parse: myCOC A 0E 07 A010 39776C 123456 010000000023 -56.5
2016.03.19 15:29:00.694 4: CUL_Parse: myCOC A 12 08 A010 39776C 123456 02041008000900000026 -55
2016.03.19 15:29:00.915 4: CUL_Parse: myCOC A 0E 09 A010 39776C 123456 010000000024 -56
2016.03.19 15:29:06.626 4: CUL_Parse: myCOC A 14 C3 A45F 3420D6 123456 83928B0075EC055308DFFF1E -59
2016.03.19 15:29:11.796 4: CUL_Parse: myCOC A 1A 01 8400 39776C 000000 1200A54D4551303037363937314004000028 -54
2016.03.19 15:29:14.626 4: CUL_Parse: myCOC A 14 C4 A45F 3420D6 123456 83929100719A053508DFFF1D -59.5
2016.03.19 15:29:22.627 4: CUL_Parse: myCOC A 14 C5 A45F 3420D6 123456 839296006B1A04DD08DEFF1E -59
2016.03.19 15:29:27.439 4: CUL_Parse: myCOC A 14 46 845E 342328 000000 80D979000000000008DDFE30 -50
2016.03.19 15:29:29.496 4: CUL_Parse: myCOC A 0D 3E 8610 4118F9 000000 06010000F1 -81.5
2016.03.19 15:29:32.532 4: CUL_Parse: myCOC A 14 C6 A45F 3420D6 123456 83929F0086C9061408DDFE1F -58.5
2016.03.19 15:29:37.286 4: CUL_Parse: myCOC A 14 B7 845E 2EAAA2 000000 814324000000000008E0FE0E -67
2016.03.19 15:29:38.626 4: CUL_Parse: myCOC A 14 C7 A45F 3420D6 123456 8392A300461E033908E0FE1F -58.5

habe meine HM-RC-Sec mal zurückgesetzt und versucht wieder zu pairen. Die reale hmID ist durch "123456" ersetzt.
Ist das denn richtig, dass hier das IODevice (myCOC) erscheint und nicht die vccu?
Schlau werde ich aus diesen Daten nicht wirklich.

Das Pairing scheint jedenfalls nicht zu funktionieren. Die FB ist "PairedTo 0x000000".
Die neue Firmware hab ich noch nicht ausprobiert.

frank · 19 März 2016, 16:10:27

ZitatDie reale hmID ist durch "123456" ersetzt.

überflüssig, denn wenn sie einer braucht, kann er sie sowieso sniffen.

123456 sendet aber überhaupt nichts laut log. aber das log sieht aus, als würde der fk antworten auf cmds geben. gibt es überhaupt mal zeilen mit "CUL_Send: myCOC", oder hast du das log gesäubert? seltsam.

probier mal direkt über coc, also mit

Code Auswählen

set myCOC hmPairForSec 3600

martinp876 · 19 März 2016, 19:12:42

Das log ist wohl manipuliert. Wichtige Infos fehlen.
Wie Frank schreibt sind alle(in Worten ALLE) messages in der Luft durch jeden(in Worten JEDEN) der in Reichweite ist problemlos mitzulesen.
Hier im Forum sind wir nicht in funktreichweite. Also keine Angst.

Klinki · 20 März 2016, 10:37:35

Genau. Es stimmt wohl etwas nicht.
Das Log ist auch nicht manipuliert - bis auf die ID.

Ich habe eine Konfiguration mit einem COC und einem Stackable COC. Einer für FS20, der andere für Homematic. Habe die Konfiguration der beiden Geräte gestern einfach mal getauscht.
Siehe da: Pairing mit vccu funktioniert. Dafür ging kein FS20 mehr.

Es scheint also irgendwie mit der Aufsteckplatine zu tun zu haben. Obwohl die Physik ja grundsätzlich funktioniert. Man kann über beide Platinen HM senden und empfangen.

Wenn niemand von euch einen Fehler in der Konfiguration entdeckt hat, wird es wohl an Firmware und / oder der Aufsteckplatine liegen.

Klinki · 21 März 2016, 17:18:57

Tja, so war es: Die COC-Aufsteckplatine durch einen USB-Stick ersetzt - alles schick.
Das COC arbeitet auf einem anderen Raspi tadellos. Die Hardware war also nicht das Problem.

Das Problem liegt dann irgendwo im Stackable_CC-Modul oder in der CUL-Firmware.

Danke an Frank und Martin, dass ihr euch meinem Problem angenommen habt!