hmKey und Index - Warum kennt ein Schalter seinen Index (und nicht seinen Key)?

[GaiusMarius]

Hallo allerseits, leider durchschaue ich den Komplex hmKey und Index nicht.

Konkret verstehe ich nicht, warum ein Gerät welches mit signing on arbeitet, einen bestimmten Index und nicht einen bestimmten Schlüssel benötigt. Jedenfalls stellt sich mir die Situation so dar.

Gegeben ist eine VCCU:

Code Auswählen Erweitern

define VCCU CUL_HM A38448
attr VCCU IODev HMLAN0
attr VCCU IOList HMLAN0,CUNO0
attr VCCU expert 2_raw
attr VCCU hmKey 01:9572ca42422e68c00b314fb7274bb864
attr VCCU model CCU-FHEM
attr VCCU subType virtual
attr VCCU webCmd virtual:update
Nach meiner Lesart ist 01 der Index, 9572ca42422e68c00b314fb7274bb864 der Schlüssel und hmKey einfach ein Speicherplatz ohne hierarchische Relevanz. Oder?

Dazu kommt ein frisch gepairter 'Schalter und Leistungsmesser' HM-ES-PMSw1.
Ich hoffe, sein define tut nichts zur Sache, da ich es weglasse. Seine Readings sind:

Code Auswählen Erweitern

aesCommToDev pending 2018-10-26 17:02:29
aesKeyNbr 06 2018-10-26 17:02:29Woher weiß das frisch gepairte Gerät, dass es irgendwann einmal an einem Index 06/2=03 gehangen hat?
Zumal die Angabe sogar richtig ist, denn der Schlüssel wurde einstmals mit 03:9572ca42422e68c00b314fb7274bb864 übertragen.

Oder bezieht sich die Indexnummer auf meinen HMLAN?

Jedenfalls ist die Konsequenz, dass, obwohl der Schlüssel an sich korrekt ist, das Gerät mit dem berühmten MISSING ACK die Arbeit verweigert.

Wo ist mein Denkfehler?



Gegenprobe: Ich gebe der VCCU wieder den Indexschlüssel 03:9572ca42422e68c00b314fb7274bb864:

Code Auswählen Erweitern

define VCCU CUL_HM A38448
attr VCCU IODev HMLAN0
attr VCCU IOList HMLAN0,CUNO0
attr VCCU expert 2_raw
attr VCCU hmKey 01:9572ca42422e68c00b314fb7274bb864
attr VCCU hmKey2 03:9572ca42422e68c00b314fb7274bb864
attr VCCU model CCU-FHEM
attr VCCU subType virtual
attr VCCU webCmd virtual:update
Und es funktioniert!

Vielen Dank und mit freudlichen Grüßen
Marius

P.S.: An alle die mich freundlicherweise darauf hinweisen möchten, meine Schlüssel nicht öffentlich zu posten: Es ist ein Fake-Schlüssel. Ich finde es besser, ein realistisches Beispiel zu wählen, als z. B. nur stumpfe XXXXXX...

[LuckyDay]

Code Auswählen Erweitern

aesKeyNbr 06

6:2 =3
4:2= 2
2:2 =1

[GaiusMarius]

Hallo fhem-hm-knecht,

danke, dass du mir geantwortet hast. Aber ich verstehe nicht, ob und wie dies meine Frage, woher ein frisch gepairtes Gerät weiß, dass es irgendwann einmal an einem Index 03 (aesKeyNbr 06) gehangen hat, adressiert.

[frank]

ein key wird einem device zugewiesen

assignHmKey
Initiates a key-exchange with the device, exchanging the old AES-key of the device with the key with the highest index defined by the attribute hmKey* in the HMLAN or VCCU. The old key is determined by the reading aesKeyNbr, which specifies the index of the old key when the reading is divided by 2.

dieser key ist dann im device eeprom gespeichert.
das device kann auch nicht mehr über knöpfchen am device resettet werden. nur noch über die zentrale mit entsprechendem key.

"frisch gepairt" kann dann eigentlich nicht stimmen.

[GaiusMarius]

"frisch gepairt" kann dann eigentlich nicht stimmen.

Unwillentlich habe ich verschwiegen, dass ich "vorher" herumexperimentiert habe. Ich habe versucht zu lernen, wie der Zusammenhang zwischen Index und Schlüssel ist und wie das Schlüsselanlernen funktioniert.

So habe ich ganz zum Schluss des Experimentierens den Schlüssel mit attr VCCU hmKey2 03:9572ca42422e68c00b314fb7274bb864 'übertragen' (inkl. assignHmKey...).

Anschließend habe ich das Gerät deletet, die Attribute hmKey2 und hmKey3 aus der VCCU entfernt, den 'richtigen' Schlüssel in hmKey mit dem Index 01 eingetragen und die VCCU in den Pairing-Modus und das Gerät in den Konfigurationsmodus versetzt, damit es neu erkannt wird.

Danach hat es, der HMLAN oder FHEM sich daran erinnert, dass das Gerät seinen Schlüssel vorher auf dem Index 03 hatte.

Und letzteres verwirrt mich...

[frank]

wie gesagt, der key ist im device gespeichert. beim deleten vom device wird im device nichts geändert. key und hmid bleiben also. es wurde also auch nichts neu gepairt, sondern in fhem nur neu angelegt und eingerichtet.

das device fordert dann ggf bei einem befehl einen konkreten schlüssel, hier keyNbr 06. daher missing_ack bis fhem auch wieder keyNbr 06 kannte.

[GaiusMarius]

das device fordert dann [...] einen konkreten schlüssel, hier keyNbr 06

Du hast genau den Teil getroffen, den ich nicht verstehe: den Zusammenhang zwischen Schlüssel (im Gerät) und dem Index (in FHEM). Wer von beiden hat sich warum an den Index erinnert?

nichts neu gepairt, sondern in fhem nur neu angelegt

Ok, ich habe den Begriff "pairen" falsch verwendet; kleiner Einwand meinerseits trotzdem: ein 'echtes' pairen wäre ja auch nicht anders abgelaufen - nur hätte das Device zu diesem Zeitpunkt noch keine Daten gehabt.

[frank]

Du hast genau den Teil getroffen, den ich nicht verstehe: den Zusammenhang zwischen Schlüssel (im Gerät) und dem Index (in FHEM). Wer von beiden hat sich warum an den Index erinnert?
Ok, ich habe den Begriff "pairen" falsch verwendet; kleiner Einwand meinerseits trotzdem: ein 'echtes' pairen wäre ja auch nicht anders abgelaufen - nur hätte das Device zu diesem Zeitpunkt noch keine Daten gehabt.

der index ist quasi der name eines keys.
da es mehrere schlüssel geben kann, muss man sich ja auf einen schlüssel einigen können.

[GaiusMarius]

Aber ich hatte das Gerät doch zwischenzeitlich deleted.

[LuckyDay]

Aber ich hatte das Gerät doch zwischenzeitlich deleted.

Deleten = löschen ist auch falsch

man muß einen unpair machen mit dem richtigen zugeteilten AES Schlüssel, und fals man den nicht hat, hat man Edel Elektroschrott.

[GaiusMarius]

Ich frage mich, ob ich es überhaupt geschafft habe, mein Anliegen klar zu machen.
Zusätzlich bin ich auch nicht mehr überzeugt davon, dass mir die Antwort bei irgendetwas Konkretem weiterhelfen wird.

Ich glaube, ich steige hier aus, probiere ein wenig herum und frage ggf. noch einmal...

Dennoch: Danke an alle!