HM protokol

[ulli]

hmm der Tip ist gut
Habe mich an "http://fhemwiki.de/wiki/HomeMatic_Devices_pairen" gehalten, aber leider ohne Erfolg.
Ich bekomme folgendes bei einem pairing Versuch

Code Auswählen Erweitern


2016.02.06 22:44:52 5: RadioGateway dispatch A1A318400467B2D0000001000C74E45513030363538313180810101
2016.02.06 22:44:52 2: CUL_HM Unknown device HM_467B2D is now defined
2016.02.06 22:44:52 2: autocreate: define HM_467B2D CUL_HM 467B2D
2016.02.06 22:44:52 3: Device HM_467B2D added to ActionDetector with 000:50 time
2016.02.06 22:44:52 3: CUL_HM pair: HM_467B2D threeStateSensor, model HM-SEC-SCo serialNr
2016.02.06 22:44:53 4: RadioGateway: SW: <A1032A0015F8E3A467B2D00050000000000>
2016.02.06 22:44:57 3: Device HM_467B2D added to ActionDetector with 000:50 time


Dann habe ich wie im Wiki beschrieben noch ein set getConfig gemacht und dann noch einmal den Pairing Button am FK gedrückt

Code Auswählen Erweitern


2016.02.06 22:45:04 3: CUL_HM set HM_467B2D getConfig
2016.02.06 22:46:24 5: RadioGateway dispatch A1A328400467B2D0000001000C74E45513030363538313180810101
2016.02.06 22:46:24 3: Device HM_467B2D added to ActionDetector with 000:50 time
2016.02.06 22:46:25 4: RadioGateway: SW: <A1033A0015F8E3A467B2D00050000000000>


Wenn ich jetzt das Fenster öffne bekomme ich folgende Meldung:

Code Auswählen Erweitern


2016.02.06 22:46:45 5: RadioGateway dispatch A0C338641467B2D000000011EC8
2016.02.06 22:46:45 4: RadioGateway: SW: <A0934A1125F8E3A467B2D>


Das Device zeigt folgendes:

Code Auswählen Erweitern


Internals:
   CFGFN
   DEF        467B2D
   IODev      RadioGateway
   LASTInputDev RadioGateway
   MSGCNT     3
   NAME       HM_467B2D
   NR         28
   NTFY_ORDER 50-HM_467B2D
   RadioGateway868_1_MSGCNT 3
   RadioGateway868_1_RAWMSG A0C338641467B2D000000011EC8
   RadioGateway868_1_TIME 2016-02-06 22:46:45
   STATE      open
   TYPE       CUL_HM
   lastMsg    No:33 - t:41 s:467B2D d:000000 011EC8
   protCmdPend 6 CMDs pending
   protLastRcv 2016-02-06 22:46:45
   protResnd  3 last_at:2016-02-06 22:46:46
   protSnd    3 last_at:2016-02-06 22:46:45
   protState  CMDs_pending
   Readings:
     2016-02-06 22:46:25   Activity        alive
     2016-02-06 22:46:25   D-firmware      1.0
     2016-02-06 22:46:25   D-serialNr      NEQ0065811
     2016-02-06 22:44:53   R-pairCentral   set_0x5F8E3A
     2016-02-06 22:46:45   battery         ok
     2016-02-06 22:46:45   contact         open (to broadcast)
     2016-02-06 22:46:45   state           open
     2016-02-06 22:46:45   trigDst_broadcast noConfig
     2016-02-06 22:46:45   trigger_cnt     30
   cmdStack:
     ++A0015F8E3A467B2D00050000000000
     ++A0015F8E3A467B2D000802010A5F0B8E0C3A
     ++A0015F8E3A467B2D0006
     ++A0015F8E3A467B2D00040000000000
     ++A0015F8E3A467B2D01040000000001
     ++A0015F8E3A467B2D0103
   Helper:
     HM_CMDNR   51
     cSnd       015F8E3A467B2D00050000000000,015F8E3A467B2D00050000000000
     getCfgList all
     getCfgListNo ,4
     mId        00C7
     rxType     28
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +467B2D,02,00,00
       nextSend   1454795093.04747
       prefIO
       rxt        2
       vccu
       p:
         467B2D
         00
         00
         00
     Mrssi:
       mNo
     Prt:
       bErr       0
       sProc      2
       wuReSent   4
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Shadowreg:
       RegL_00.    02:01 0A:5F 0B:8E 0C:3A
Attributes:
   IODev      RadioGateway
   actCycle   000:50
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-SEC-SCo
   room       System
   serialNr   NEQ0065811
   subType    threeStateSensor


Scheinbar funktioniert das Pairing überhaupt nicht. Muss ich vorher einen neuen AES Schlüssel setzen oder an was denkst du liegt das?

Zusatzfrage:
An was hängt das wenn CMDs pending sind. Warum schickt er die nicht raus? Auf was wartet er denn?

[frank]

An was hängt das wenn CMDs pending sind. Warum schickt er die nicht raus? Auf was wartet er denn?

das device muss aufwachen.
da der sco lazyconfig kann, entweder fensterstatus ändern oder configtaster drücken.
mit set clear msgEvents kann man die queue löschen.

[MarcelK]

An was hängt das wenn CMDs pending sind. Warum schickt er die nicht raus? Auf was wartet er denn?

Wie Frank schon richtig anmerkte, das Device soll ja Jahre mit einer Batterie überleben, das heißt es schläft praktisch immer und ist nie auf Empfang. Außer eben kurz nachdem es selbst etwas gesendet hat, das ist genau die Lücke wo FHEM mit "HAVE_DATA" kurz sagen will dass es bitte nicht sofort wieder einschlafen soll.

Die Pairing Request Anforderung vom Sensor wurde in FHEM richtig empfangen, das sieht man u.A. am "Firmware" bzw "serialNr" Eintrag, die richtig gesetzt wurden. Ich vermute aber dass Du noch ein Problem mit dem Senden hast:

2016-02-06 22:44:53   R-pairCentral   set_0x5F8E3A

Heißt er hat versucht den Request zu senden, das wurde bisher aber nicht bestätigt. Wenn das Pairing erfolgreich gewesen wäre dann würde das "set_" nicht mehr da stehen.

Gruß Marcel

[ulli]

Danke, ich komme zum Glück immer ein Stück weiter Danke euch!
Wichtig zu wissen ist das der CC1101 scheinbar doch CRC aktiviert hat und das natürlich beim TX an den FK essentiell ist.

Ich habe nun folgende Infos aus einem "list" nachdem ich den Pairing-Button gedrück habe.

Code Auswählen Erweitern


Internals:
   CFGFN
   DEF        467B2D
   IODev      RadioGateway868_1
   LASTInputDev RadioGateway868_1
   MSGCNT     4
   NAME       HM_467B2D
   NR         27
   NTFY_ORDER 50-HM_467B2D
   RadioGateway868_1_MSGCNT 4
   RadioGateway868_1_RAWMSG A1A0E8400467B2D0000001000C74E45513030363538313180810101
   RadioGateway868_1_TIME 2016-02-09 18:08:36
   STATE      open
   TYPE       CUL_HM
   lastMsg    No:0E - t:00 s:467B2D d:000000 1000C74E45513030363538313180810101
   protCmdPend 4 CMDs pending
   protLastRcv 2016-02-09 18:08:36
   protResnd  3 last_at:2016-02-09 18:08:39
   protSnd    5 last_at:2016-02-09 18:08:36
   protState  CMDs_pending
   Readings:
     2016-02-09 18:08:36   Activity        alive
     2016-02-09 18:08:36   D-firmware      1.0
     2016-02-09 18:08:36   D-serialNr      NEQ0065811
     2016-02-09 18:07:40   R-pairCentral   set_0x5F8E3A
     2016-02-09 18:07:40   aesKeyNbr       00
     2016-02-09 18:08:28   battery         ok
     2016-02-09 18:08:28   contact         open (to broadcast)
     2016-02-09 18:08:28   state           open
     2016-02-09 18:08:28   trigDst_broadcast noConfig
     2016-02-09 18:08:28   trigger_cnt     19
   cmdStack:
     ++A0015F8E3A467B2D000802010A5F0B8E0C3A
     ++A0015F8E3A467B2D0006
     ++A0015F8E3A467B2D00040000000000
     ++A0015F8E3A467B2D01040000000001
     ++A0015F8E3A467B2D0103
   Helper:
     HM_CMDNR   15
     cSnd       015F8E3A467B2D000802010A5F0B8E0C3A,015F8E3A467B2D000802010A5F0B8E0C3A
     getCfgList all
     getCfgListNo ,4
     mId        00C7
     rxType     28
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +467B2D,02,00,00
       nextSend   1455037716.89817
       prefIO
       rxt        2
       vccu
       p:
         467B2D
         00
         00
         00
     Mrssi:
       mNo
     Prt:
       bErr       0
       sProc      2
       wuReSent   4
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Shadowreg:
       RegL_00.    02:01 0A:5F 0B:8E 0C:3A
Attributes:
   IODev      RadioGateway868_1
   actCycle   000:50
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-SEC-SCo
   room       System
   serialNr   NEQ0065811
   subType    threeStateSensor


Komischerweise habe ich nach einem "getconfig" und einem wiederholten Drücken auf den Paring Butten am FK immer noch CMDs im pending.
Aber es ist nun ein Datenaustausch erkennbar über die Logs und ein paar Readings(siehe oben)sind dazu gekommen:

Code Auswählen Erweitern


2016.02.09 18:07:40 4: RadioGateway: <A1A0B8400467B2D0000001000C74E45513030363538313180810101>
2016.02.09 18:07:40 2: CUL_HM Unknown device HM_467B2D is now defined
2016.02.09 18:07:40 2: autocreate: define HM_467B2D CUL_HM 467B2D
2016.02.09 18:07:40 3: Device HM_467B2D added to ActionDetector with 000:50 time
2016.02.09 18:07:40 3: CUL_HM pair: HM_467B2D threeStateSensor, model HM-SEC-SCo serialNr
2016.02.09 18:07:40 4: RadioGateway: SW: <A100CA0015F8E3A467B2D00050000000000>
2016.02.09 18:07:40 4: RadioGateway: <A10CA002467B2D5F8E3A0494584C91105B00>
2016.02.09 18:07:40 4: RadioGateway: SW: <A0A0C80025F8E3A467B2D00>
2016.02.09 18:07:40 4: RadioGateway: SW: <A130DA0015F8E3A467B2D000802010A5F0B8E0C3A>
2016.02.09 18:07:45 3: Device HM_467B2D added to ActionDetector with 000:50 time
2016.02.09 18:08:24 3: CUL_HM set HM_467B2D getConfig
2016.02.09 18:08:28 4: RadioGateway: <A0C0D8641467B2D0000000113C8>
2016.02.09 18:08:28 4: RadioGateway: SW: <A090EA1125F8E3A467B2D>
2016.02.09 18:08:36 4: RadioGateway: <A1A0E8400467B2D0000001000C74E45513030363538313180810101>
2016.02.09 18:08:36 3: Device HM_467B2D added to ActionDetector with 000:50 time
2016.02.09 18:08:36 4: RadioGateway: SW: <A130FA0015F8E3A467B2D000802010A5F0B8E0C3A>


Ist das so korrekt? Obwohl das Reading R-pairCentral immer noch ein "set_" hat und Commands noch pending sind?

[frank]

Ist das so korrekt? Obwohl das Reading R-pairCentral immer noch ein "set_" hat und Commands noch pending sind?

das knöpchen drücken wiederholen, bis alles abgearbeitet ist => cmds_done.

[ulli]

Ich brauche dringend noch einmal eure Hilfe. Ich bekomme den FK immer noch nicht gepaired.
Ich vermute es liegt daran das die letzten beiden Nachrichten scheinbar nicht ankommen.
Die Kommunikation sieht wie folgt aus:

A1A788400467B2D0000001000C74E45513030363538313180810101 [RSSI:-92]
--> Pairing Anfrage vom FK
As1079A0015F8E3A467B2D00050000000000 [RSSI:-53]
--> Start Config von FHEM
A1179A002467B2D5F8E3A040D227BE021A900 [RSSI:-103]
--> Antwort von FK
As0A7980025F8E3A467B2D00 [RSSI:-53]
--> Ich denke ACK von FHEM
As137AA0015F8E3A467B2D000802010A5F0B8E0C3A [RSSI:-53]
--> Nochmal eine Nachricht von FHEM

Komischerweise bekomme ich nur zweimal eine Antwort vom FK, ist das Normal?
Ich habe auch schon die Delay Zeit zwischen den Kommandos von 0ms auf 1ms gerastet....immer mit gleichem Verhalten.
Ich dachte es kommen immer Abwechseln Nachrichten von FK<->FHEM?

Und zu aller Irritation bleibt dann immer 1 CMD pending....

Habt Ihr einen Tip warum das Pairing abbricht?

[frank]

schau dir mal die rssi an. warum sind die richtungen so unterschiedlich?

[ulli]

Das liegt daran das ich durch ein drittGerät das ganze aufgezeichnet habe welches weiter weg stand.
Mein RfM69 hat auch eine höhere Sendeleistung wie es vermutlich der FK hat.

[frank]

die rssi vom fk sind grotten schlecht, da könnte also etwas fehlen.
der fk möchte jedenfalls eine aes authentifizierung (A002), was fhem wohl auch macht. den genauen ablauf müsstest du im forum finden => suche nach mgernoth/aes.
wichtig wären timestamps wegen timing. wenn du eh schon monitorst, solltest du auf diesem cul? die fw mit timestamps installieren, siehe angepinnter thread. vielleicht ist fhem zu spät und der fk schläft schon wieder.

[ulli]

Hmm AES ist ein guter Punkt. Ich dachte ich kann pairen ohne AES. (Ist der key nicht erst setzbar wenn die zwei Devices gepaired sind?)

Kann ich über einen CUL bei einem FK ohne pairing oder im pairing Prozess selbst das AES vorerst deaktivieren?

[frank]

fk werden seit einiger zeit mit aktiviertem aes ausgeliefert. defaultschlüssel. sollte ein cul mit fhem können. eine entsprechende antwort kommt ja wohl auch.
ob ein ungepairtes device befehle entgegennimmt wiess ich nicht, schätze aber nein. zum aes ausschalten wird aber sowieso aes benötigt.

[ulli]

Was heißt das jetzt?
Muss ich einen neuen AES setzten bevor ich erfolgreich Pairen kann?

Ich versuche aktuell folgendes:
1) Werkseinstellungen des FK
2) hmID des CUL setzten, Pairing Zeit auf 600
3) Pairing Knopf am FK drücken.
--> Nicht alle Befehle werden ausgeführt/vom FK bestätigt. Daher kein erfolgreiches Pairing...

[Otto123]

Hallo Ulli

Du musst nicht AES setzen zum pairen, das geht auch ohne zumindest mit meinem HMLAN (der CUL sollte es mittlerweile können)

Aber die Sensoren brauchen manchmal Zeit, wenn nicht alles rüberkommt musst Du nach etwas Zeit nochmal den Anlernknopf drücken. Manchmal auch dreimal.

Die Zeit fürs Pairing ist egal, es sei denn Du bist ganz langsam  das "Parrungsbereitschaft" wird eh nach dem ersten Pairing Message Austausch ausgeschaltet.

Gruß Otto

[ulli]

Ich habe schon so oft auf den Pairing Knopf gedrückt das er vermutlich bald über der Auslegungsgrenze betätigt wurde

Komischerweise läuft nur das Pairing nicht durch (also die letzten beiden Kommands)
Wenn ich nach einem "set clear MsgEvents" ein getConfig ausführe und dann den Pairing Butten drücke ist die gesamte Config sauber da.

ich Vermute das letzte unbeantwortete Kommando von FHEM an den FK ist evtl. falsch:
"As0A7980025F8E3A467B2D00"
Weil ab diesem bekomme ich keine Antwort mehr vom FK. Obwohl aber die LED nach dem absetzen des Kommandos:
"As1079A0015F8E3A467B2D00050000000000"
eine grüne LED anzeigt.

Scheinbar akzeptiert der FK das Kommando "As0A7980025F8E3A467B2D00" nicht oder erwartet nicht das noch etwas nach dem "As1079A0015F8E3A467B2D00050000000000" kommt?

Ich bin auch mal in die Tiefen des Protocols eingestiegen und musste feststellen das das CUL_HM doch vermutlich was durcheinander bringt?
(QUelle: https://homegear.eu/index.php/BidCoS_Packet_-_0x01_0x08)
Scheinbar müsste nach dem Config_Start welche nach der Pairing Anfrage vom FK von CUL_HM versendet wird ein anderes Kommando mit "A001" folgen.
Auch der FK antwortet nicht mit einem ACK ("8002") auf das Config_Start Kommando von FHEM.

Jetzt check ich garnichts mehr.

[MarcelK]

A1179A002467B2D5F8E3A040D227BE021A900 [RSSI:-103]
--> Antwort von FK

"Antwort von FK" ist hier ein bisschen zu lapidar. Die Antwort ist nämlich ein Request für ein AES signiertes ACK. "0D227BE021A9" ist die Challenge, "00" ist die Key-Nummer (also der HM Default Key)

As0A7980025F8E3A467B2D00 [RSSI:-53]

Worauf Du hier einen nicht signierten ACK zurücksendest. Kein Wunder mag Dich der Sensor nicht

In CUL_HM wird, wenn das Interface vom Typ "CUL" ist, das AES Handling vom Code übernommen, ansonsten nicht. Das dürfte an dieser Stelle Dein Problem sein.

Gruß Marcel