HM-SEC-SC-2 und aesCommReq

[ambiman]

Hallo zusammen,

ich habe heute meinen Fensterkontakt im Bad auf AES-Signatur umgestellt. Die Zuweisung des Schlüssels sowie anschließendes Setzen der Register R-sign (zur Anforderung von Signaturen) sowie R-Heizung_Bad_WindowRec-expectAES (zwecks signierter Verbindung zwischen Fensterkontakt und dem Heizungsthermostat) waren erfolgreich.
Ich sehe folgende Readings:

Code Auswählen Erweitern

2015-11-07 14:32:47   aesCommToDev    ok
2015-11-07 14:30:19   aesKeyNbr       02 

... welche ein Indiz dafür sind, das die Kommunikation erfolgreich ist.

Nun möchte ich auch eine signierte Verbindung zwischen dem HM-SEC-SC-2 und dem CUL (zwecks Alarmanlage) erzwingen - daher habe ich das Userattribut aesCommReq auf 1 gesetzet (wie auch bei meinen anderen Aktoren).

Anschließend ist die Kommunikation leider nicht mehr möglich, mann kann beim Öffen / Schließen des Fensters auch erkennen, dass min. ein Empfänger (CUL) nicht erreicht werden kann - LED leuchtet lange und anschließend kurz rot. Die Verbindung zum Thermostat zwecks WindowRec funktioniert jedoch weiterhin tadellos. Entfernt man das Attribut aesCommReq wieder, ist alles wieder ok.

Kann der HM-SEC-SC-2 nur mit einem Empfänger signiert kommunizieren?

Danke für Eure Unterstützung!

Gruß,

ambiman

[ambiman]

Hat niemand eine Idee?

[ambiman]

Hallo zusammen,

ich habe nun einen zweiten und dritten Fensterkontakt in Betrieb genommen und festgestellt, dass das Problem einfach zu reproduzieren ist:

Sobald ich das Attribut aesCommReq auf 1 setze, leuchtet der HM-SEC-SC-2 bei einer Statusänderung (open/closed) lange orange und anschließend kurz rot. Währenddessen wechselt der Status der Reading saesCommToDev immer zwischen pending un dok. Der Status wird jedoch übertragen.

Entferne ich das Attribut, erhalte ich ein kurzes grünes Leuchten und alles ist OK.

Da ich den HM-SEC-SC-2 als wichtigen Bestandteil meiner Alarmanlage nutzen möchten, wäre es schon gut, wenn er die Statusmeldungen signiert an FHEM überträgt.

Hat denn niemand eine Idee woran es liegen kann?

Gruß,

ambiman

[martinp876]

nun, FHEM will eine bestätigung der Quelle wenn das Attribut gesetzt ist. Offensichtlich stimmt die signatur nicht.

[ambiman]

Hallo zusammen,

das habe ich mir schon gedacht.
Ich verstehe jedoch nicht weshalb die signierte Antwort des Fensterkontakts nicht akzeptiert wird.

Das assignHmKey hat funktioniert, der Index des Readings aesKeyNbr wird hochgezählt (nach dem ersten assignHmKey war das Reading lange Zeit 00 - hierzu musste das 'sign' Reading of on gesetzt werden und anschließend eine Aktion ausgeführt werden, welche eine Signatur erfordert - in meinem Fall hat ein "set <device> regSet cyclicInfoMsg on" zum gewünschten Erfolg geführt).

Dennoch bleibt das Problem bei der Statusänderung (Fenster/Tür auf/zu) mit aktivierer Signaturprüfung per aesCommReq.
Die LED des Kontakts leuchtet weiterhin lange orange und dann kurz rot.

Hat es jemand mal geschafft valide signierte Antworten eines HM-SEC-SC-2 Fensterkontakts mit aktiviertem aesCommReq auf Seiten eines CUL zu verarbeiten ?

Folgendes findet sich im Log:

Code Auswählen Erweitern


2015.12.18 17:31:43 4: CUL_Parse: CUL_0 A 0C 03 A241 <HMID-FENSTERKONTAKT> <HMID-VCCU> 01030004 -72
2015.12.18 17:31:43 5: CUL_HM Fenster_GZ requesting signature with challenge B2F79AB98F58 for key 2
2015.12.18 17:31:43 4: CUL_send:  CUL_0As 11 03 A002 <HMID-VCCU> <HMID-FENSTERKONTAKT> 04B2F79AB98F5804
2015.12.18 17:31:43 5: Triggering Fenster_GZ (1 changes)
2015.12.18 17:31:43 5: Notify loop for Fenster_GZ aesCommToDev: pending
2015.12.18 17:31:46 4: CUL_Parse: CUL_0 A 0C 03 A241 <HMID-FENSTERKONTAKT> <HMID-VCCU> 010300F6 -79
2015.12.18 17:31:46 5: CUL_HM Fenster_GZ requesting signature with challenge B2F79AB98F58 for key 2
2015.12.18 17:31:46 4: CUL_send:  CUL_0As 11 03 A002 <HMID-VCCU> <HMID-FENSTERKONTAKT> 04B2F79AB98F5804
2015.12.18 17:31:46 5: Triggering Fenster_GZ (1 changes)
2015.12.18 17:31:46 5: Notify loop for Fenster_GZ aesCommToDev: pending
2015.12.18 17:31:47 4: CUL_Parse: CUL_0 A 19 03 A203 <HMID-FENSTERKONTAKT> <HMID-VCCU> 906D7B93CF0C6308AF926A7336E61283FC -76
2015.12.18 17:31:47 5: CUL_HM VCCU_0 iv: 0300
             decrypted cmd: 03A241<HMID-FENSTERKONTAKT><HMID-VCCU>01
             original  cmd: 03A241<HMID-FENSTERKONTAKT><HMID-VCCU>01
2015.12.18 17:31:47 4: CUL_HM VCCU_0 signature: good, authbytes: 11279942
2015.12.18 17:31:47 4: CUL_HM protstate undeviced hash to set CMDs_done
2015.12.18 17:31:47 4: CUL_HM Fenster_GZ dupe: repeat 2 ack, dont process
2015.12.18 17:31:47 5: Triggering Fenster_GZ (2 changes)
2015.12.18 17:31:47 5: Notify loop for Fenster_GZ aesCommToDev: ok


Die zugehörigen Readings:

Code Auswählen Erweitern


2015-12-18 17:30:18   aesCommToDev    ok
2015-12-18 17:30:18   aesKeyNbr       04
2015-12-15 20:06:49   R-sign          on


Danke & viele Grüße,

ambiman

[MarcelK]

Das assignHmKey hat funktioniert, der Index des Readings aesKeyNbr wird hochgezählt (nach dem ersten assignHmKey war das Reading lange Zeit 00 - hierzu musste das 'sign' Reading of on gesetzt werden und anschließend eine Aktion ausgeführt werden, welche eine Signatur erfordert - in meinem Fall hat ein "set <device> regSet cyclicInfoMsg on" zum gewünschten Erfolg geführt)

Ich kann Dir zwar leider nicht weiterhelfen (mit meinem HMLAN läuft's), aber vielen Dank für den Hinweis zum Erzwingen des Schlüssel-Wechsels! Mit der Windows-Software ging das immer sofort, ich hab echt schon graue Haare bekommen wieso aesKeyNbr mit der FHEM Methode immer auf 0 verbleibt... jetzt passt's

Besten Gruß, Marcel

[Rampler]

Kann es sein, dass es am Sensor selbst liegt, bei den "alten" funktionierts (HM-SEC-SC) einwandfrei.
Zumindest scheint es damit Probleme zu geben, guckst du http://www.elv.de/topic/hm-sec-sc2.html

Wichtige Hinweise:

- Der "HM-Sec-Sc2" ist nicht mehr kompatibel zur BidCos Alarmzentrale! Es wird jedoch in Kürze wieder einige HM-Sec-Sc" (ohne -2) geben, die dann auch an der BidCos Alarmzentrale angemeldet werden können.

- Die neuen HM-RC4-2 Handsender können ebenfalls nicht mit der BidCos Alarmzentrale kombiniert werden!

- Ein Up- bzw. Downgrade-Service der Firmware kann nicht durchgeführt werden!

Mal nach Firmware gesucht ?

Was sagt den protEvt_AESCom-ok bei den internals ?

[ambiman]

Hallo,

protEvt_AESCom-ok schaut so aus:

Code Auswählen Erweitern


protEvt_AESCom-ok 23 last_at:2015-12-19 13:09:13


Danke für den Hinweis mit der Firmware, diese scheint jedoch aktuell zu sein:

Code Auswählen Erweitern


2015-12-19 14:18:09   D-firmware      2.4


Code Auswählen Erweitern


HM75654 HM-Sec-SC-2 Funk-Tür-Fensterkontakt (magnetisch) 2.4   11.03.2014


Quelle: http://www.homematic-inside.de/hardware/firmware-versions

Viele Grüße,

ambiman

[Rampler]

Einmal langes, zweimal kurzes
Blinken, Pause
(2 Wiederholungen)
==
Batteriespannung zu
gering

Oder Empfangsprobleme, was sagt der RSSI Wert ?

Evtl. einen Versuch Wert ...

[ambiman]

Hi Rampler,

der Kontakt leuchtet dauerhaft orange und dann kurz rot - dies soll eine Indikation dafür sein,
dass er min. einen Empfänger (CUL) nicht erreichen kann.

RSSI:

Code Auswählen Erweitern


rssi_at_CUL_0 avg:-83.23 min:-97.5 max:-63.5 lst:-82.5 cnt:115


Viele Grüße,

ambiman

[mgernoth]

Hallo,

das Problem in dem Fall scheint mir zu sein, dass Fhem hier ein Duplikat erkennt und selbst kein Ack erzeugt, weswegen der Sensor rot leuchtet:

Code Auswählen Erweitern


2015.12.18 17:31:47 4: CUL_HM VCCU_0 signature: good, authbytes: 11279942
2015.12.18 17:31:47 4: CUL_HM protstate undeviced hash to set CMDs_done
2015.12.18 17:31:47 4: CUL_HM Fenster_GZ dupe: repeat 2 ack, dont process


Hier muesste Fhem eigentlich ein Ack mit den entschluesselten Authbytes 11279942 erzeugen und senden. Warum es das nicht tut, kann ich nicht sagen, da ist der AES Code schon durchlaufen und das Kommando im "normalen" CUL_HM. Evtl. weiss hier Martin weiter.

Viele Gruesse
  Michael

[martinp876]

Muss ich testen. Den AES teil habe ich bekommen, nicht selbst implementiert.
Ich muss meine Installation nachrüsten, dann kann ich probieren, warum das ACK nicht kommt. Gut möglich, dass es klemmt.....

[mgernoth]

Hi,

Muss ich testen. Den AES teil habe ich bekommen, nicht selbst implementiert.

Ich fühle mich schuldig

Das Problem ist, dass im dupe-Handling (Zeile 1268) die Authbytes nicht ins ACK gepackt werden. Da sie in der normalen ACK-Behandlung auch gelöscht werden (Zeile 2599), weiss ich gerade keinen schönen Weg, an dieser Stelle auf sie zuzugreifen.

EDIT: Ist kein Problem, aesAuthBytes wird auf jeden Fall davor neu gesetzt.
EDIT2: Patch attached, bitte mal testen.

Viele Grüße
  Michael

[ambiman]

Hallo zusammen,

zunächst erstmal vielen Dank für die kompetente Unterstützung.
Ich habe den Patch eingespielt und FHEM neu gestartet.
Leider brachte die Änderung keinen  Erfolg - der Kontakt verhält sich weiterhin wie oben beschrieben.
Anbei das Log:

Code Auswählen Erweitern


2015.12.24 14:20:22 5: CUL/RAW: /A0CB8A641<HMID-FENSTERKONTAKT><HMID-VCCU>01B00006

2015.12.24 14:20:22 4: CUL_Parse: CUL_0 A 0C B8 A641 <HMID-FENSTERKONTAKT> <HMID-VCCU> 01B00006 -71
2015.12.24 14:20:22 5: CUL_0 dispatch A0CB8A641<HMID-FENSTERKONTAKT><HMID-VCCU>01B000::-71:CUL_0
2015.12.24 14:20:22 5: CUL_HM Kueche_Terrassentuer requesting signature with challenge 4BCCFE5DBC02 for key 2
2015.12.24 14:20:22 5: CUL_0 sending As11B8A002<HMID-VCCU><HMID-FENSTERKONTAKT>044BCCFE5DBC0204
2015.12.24 14:20:22 5: CUL <HMID-FENSTERKONTAKT> dly:88ms
2015.12.24 14:20:22 4: CUL_send:  CUL_0As 11 B8 A002 <HMID-VCCU> <HMID-FENSTERKONTAKT> 044BCCFE5DBC0204
2
2015.12.24 14:20:22 5: CUL/RAW: /A19B8A203<HMID-FENSTERKONTAKT><HMID-VCCU>40E3C1AD335B4D6AF7CB19C8CBB55537FE

2015.12.24 14:20:22 4: CUL_Parse: CUL_0 A 19 B8 A203 <HMID-FENSTERKONTAKT> <HMID-VCCU> 40E3C1AD335B4D6AF7CB19C8CBB55537FE -75
2015.12.24 14:20:22 5: CUL_0 dispatch A19B8A203<HMID-FENSTERKONTAKT><HMID-VCCU>40E3C1AD335B4D6AF7CB19C8CBB55537::-75:CUL_0
2015.12.24 14:20:22 5: CUL_HM VCCU_0 iv: b000
             decrypted cmd: B8A641<HMID-FENSTERKONTAKT><HMID-VCCU>01
             original  cmd: B8A641<HMID-FENSTERKONTAKT><HMID-VCCU>01
2015.12.24 14:20:22 4: CUL_HM VCCU_0 signature: good, authbytes: a5ce5224
2015.12.24 14:20:22 5: CUL_HM Kueche_Terrassentuer prep ACK for 01
2015.12.24 14:20:22 5: CUL_0 sending As11B88002<HMID-VCCU><HMID-FENSTERKONTAKT>0101C800a5ce5224
2015.12.24 14:20:22 5: CUL <HMID-FENSTERKONTAKT> dly:71ms
2015.12.24 14:20:22 4: CUL_send:  CUL_0As 11 B8 8002 <HMID-VCCU> <HMID-FENSTERKONTAKT> 0101C800a5ce5224
2015.12.24 14:20:22 5: CUL_HM Kueche_Terrassentuer protEvent:CMDs_done
2015.12.24 14:20:22 5: CUL_HM Kueche_Terrassentuer sent ACK:2
2015.12.24 14:20:22 5: CUL/RAW: /A0F5986103CDBDD0000000A90BE10030019

2015.12.24 14:20:22 4: CUL_Parse: CUL_0 A 0F 59 8610 3CDBDD 000000 0A90BE10030019 -61.5
2015.12.24 14:20:22 5: CUL_0 dispatch A0F5986103CDBDD0000000A90BE100300::-61.5:CUL_0
2015.12.24 14:20:22 5: CUL/RAW: /A0CB8A241<HMID-FENSTERKONTAKT><HMID-VCCU>01B000FC

2015.12.24 14:20:22 4: CUL_Parse: CUL_0 A 0C B8 A241 <HMID-FENSTERKONTAKT> <HMID-VCCU> 01B000FC -76
2015.12.24 14:20:22 5: CUL_0 dispatch A0CB8A241<HMID-FENSTERKONTAKT><HMID-VCCU>01B000::-76:CUL_0
2015.12.24 14:20:22 5: CUL_HM Kueche_Terrassentuer requesting signature with challenge 097BE6B86643 for key 2
2015.12.24 14:20:22 5: CUL_0 sending As11B8A002<HMID-VCCU><HMID-FENSTERKONTAKT>04097BE6B8664304
2015.12.24 14:20:22 5: CUL <HMID-FENSTERKONTAKT> dly:88ms
2015.12.24 14:20:22 4: CUL_send:  CUL_0As 11 B8 A002 <HMID-VCCU> <HMID-FENSTERKONTAKT> 04097BE6B8664304
2015.12.24 14:20:23 5: CUL/RAW: /A0CB8A241<HMID-FENSTERKONTAKT><HMID-VCCU>01B000F8

2015.12.24 14:20:23 4: CUL_Parse: CUL_0 A 0C B8 A241 <HMID-FENSTERKONTAKT> <HMID-VCCU> 01B000F8 -78
2015.12.24 14:20:23 5: CUL_0 dispatch A0CB8A241<HMID-FENSTERKONTAKT><HMID-VCCU>01B000::-78:CUL_0
2015.12.24 14:20:23 5: CUL_HM Kueche_Terrassentuer requesting signature with challenge 097BE6B86643 for key 2
2015.12.24 14:20:23 5: CUL_0 sending As11B8A002<HMID-VCCU><HMID-FENSTERKONTAKT>04097BE6B8664304
2015.12.24 14:20:23 5: CUL <HMID-FENSTERKONTAKT> dly:88ms
2015.12.24 14:20:23 4: CUL_send:  CUL_0As 11 B8 A002 <HMID-VCCU> <HMID-FENSTERKONTAKT> 04097BE6B8664304
2015.12.24 14:20:23 5: CUL/RAW: /A19B8A203<HMID-FENSTERKONTAKT><HMID-VCCU>8824CBC063171B90BD652911D471B025F7

2015.12.24 14:20:23 4: CUL_Parse: CUL_0 A 19 B8 A203 <HMID-FENSTERKONTAKT> <HMID-VCCU> 8824CBC063171B90BD652911D471B025F7 -78.5
2015.12.24 14:20:23 5: CUL_0 dispatch A19B8A203<HMID-FENSTERKONTAKT><HMID-VCCU>8824CBC063171B90BD652911D471B025::-78.5:CUL_0
2015.12.24 14:20:23 5: CUL_HM VCCU_0 iv: b000
             decrypted cmd: B8A241<HMID-FENSTERKONTAKT><HMID-VCCU>01
             original  cmd: B8A241<HMID-FENSTERKONTAKT><HMID-VCCU>01
2015.12.24 14:20:23 4: CUL_HM VCCU_0 signature: good, authbytes: 301c6ba8
2015.12.24 14:20:23 4: CUL_HM protstate undeviced hash to set CMDs_done
2015.12.24 14:20:23 4: CUL_HM Kueche_Terrassentuer dupe: repeat 2 ack, dont process
2015.12.24 14:20:24 5: CUL/RAW: /A0CB8A241<HMID-FENSTERKONTAKT><HMID-VCCU>01B00007

2015.12.24 14:20:24 4: CUL_Parse: CUL_0 A 0C B8 A241 <HMID-FENSTERKONTAKT> <HMID-VCCU> 01B00007 -70.5
2015.12.24 14:20:24 5: CUL_0 dispatch A0CB8A241<HMID-FENSTERKONTAKT><HMID-VCCU>01B000::-70.5:CUL_0
2015.12.24 14:20:24 5: CUL_HM Kueche_Terrassentuer requesting signature with challenge 87A62B28E142 for key 2
2015.12.24 14:20:24 5: CUL_0 sending As11B8A002<HMID-VCCU><HMID-FENSTERKONTAKT>0487A62B28E14204
2015.12.24 14:20:24 5: CUL <HMID-FENSTERKONTAKT> dly:87ms
2015.12.24 14:20:24 4: CUL_send:  CUL_0As 11 B8 A002 <HMID-VCCU> <HMID-FENSTERKONTAKT> 0487A62B28E14204
2015.12.24 14:20:24 5: CUL/RAW: /A19B8A203<HMID-FENSTERKONTAKT><HMID-VCCU>CC653B394701A04F3775C2098ACEBE4205

2015.12.24 14:20:24 4: CUL_Parse: CUL_0 A 19 B8 A203 <HMID-FENSTERKONTAKT> <HMID-VCCU> CC653B394701A04F3775C2098ACEBE4205 -71.5
2015.12.24 14:20:24 5: CUL_0 dispatch A19B8A203<HMID-FENSTERKONTAKT><HMID-VCCU>CC653B394701A04F3775C2098ACEBE42::-71.5:CUL_0
2015.12.24 14:20:24 5: CUL_HM VCCU_0 iv: b000
             decrypted cmd: B8A241<HMID-FENSTERKONTAKT><HMID-VCCU>01
             original  cmd: B8A241<HMID-FENSTERKONTAKT><HMID-VCCU>01
2015.12.24 14:20:24 4: CUL_HM VCCU_0 signature: good, authbytes: 9dfbcfa1
2015.12.24 14:20:24 4: CUL_HM protstate undeviced hash to set CMDs_done
2015.12.24 14:20:24 4: CUL_HM Kueche_Terrassentuer dupe: repeat 2 ack, dont process
2015.12.24 14:20:26 5: CUL/RAW: /A0CB8A241<HMID-FENSTERKONTAKT><HMID-VCCU>01B0000A

2015.12.24 14:20:26 4: CUL_Parse: CUL_0 A 0C B8 A241 <HMID-FENSTERKONTAKT> <HMID-VCCU> 01B0000A -69
2015.12.24 14:20:26 5: CUL_0 dispatch A0CB8A241<HMID-FENSTERKONTAKT><HMID-VCCU>01B000::-69:CUL_0
2015.12.24 14:20:26 5: CUL_HM Kueche_Terrassentuer requesting signature with challenge 74767DDB7340 for key 2
2015.12.24 14:20:26 5: CUL_0 sending As11B8A002<HMID-VCCU><HMID-FENSTERKONTAKT>0474767DDB734004
2015.12.24 14:20:26 5: CUL <HMID-FENSTERKONTAKT> dly:87ms
2015.12.24 14:20:26 4: CUL_send:  CUL_0As 11 B8 A002 <HMID-VCCU> <HMID-FENSTERKONTAKT> 0474767DDB734004
2015.12.24 14:20:26 5: CUL/RAW: /A19B8A203<HMID-FENSTERKONTAKT><HMID-VCCU>15619BC8822FD1930615123875D1993E08

2015.12.24 14:20:26 4: CUL_Parse: CUL_0 A 19 B8 A203 <HMID-FENSTERKONTAKT> <HMID-VCCU> 15619BC8822FD1930615123875D1993E08 -70
2015.12.24 14:20:26 5: CUL_0 dispatch A19B8A203<HMID-FENSTERKONTAKT><HMID-VCCU>15619BC8822FD1930615123875D1993E::-70:CUL_0
2015.12.24 14:20:26 5: CUL_HM VCCU_0 iv: b000
             decrypted cmd: B8A241<HMID-FENSTERKONTAKT><HMID-VCCU>01
             original  cmd: B8A241<HMID-FENSTERKONTAKT><HMID-VCCU>01
2015.12.24 14:20:26 4: CUL_HM VCCU_0 signature: good, authbytes: caf31afa
2015.12.24 14:20:27 4: CUL_HM protstate undeviced hash to set CMDs_done
2015.12.24 14:20:27 4: CUL_HM Kueche_Terrassentuer dupe: repeat 2 ack, dont process


Und die Readings:

Code Auswählen Erweitern


2015-12-24 14:20:50   aesCommToDev    ok
2015-12-24 14:12:30   aesKeyNbr       04


Frohe Weihnachten und viele Grüße,

ambiman

[martinp876]

Muss ich durchsehen
Nur vorab: das ausblenden der hmid ist nicht notwendig. Jeder, der neben deinem Haus snifft kann sie in Klartext lesen.
Wichtig ist einzig, die Zuweisung des keys nicht zu veröffentlichen. ALLES im Normalbetrieb kann JEDER lesen, der bei dir in der Nähe ist. Alle anderen können nichts damit anfangen, zu weit web.