Umstieg von HM-CFG-LAN auf VCCU - was ist mit AES?

[mrichwin]

Hallo zusammen,

ich hätte da gerne mal ein Problem...

Zur Zeit habe ich (u.a.) eine Anzahl von Rauchmeldern (HM-SEC-SD-2) direkt an einen HM-CFG-LAN gepaired. Ich habe mich damals nicht näher mit dem Thema AES befasst, aber wenn ich das richtig verstehe brauchen die Rauchmelder die AES-Signatur auf der Funkstrecke. Insbesondere sehe ich keine hmKey-Einträge in der fhem.cfg. Die Rauchmelder haben "aesCommToDev ok" und "aesKeyNbr 00" readings, von daher gehe ich davon aus, dass hier der Standard-Key aus dem HM-CFG-LAN verwendet wird.

Ich plane nun, eine VCCU einzurichten, um die Abdeckung mittels eines zweiten IODev (ein vorhandener COC auf einem RPi) zu verbessern. Dabei muss ja irgendwie ein neuer AES-Key in die VCCU, und die existierenden Devices müssen dem neuen Key vertrauen.

Kann mir da jemand der Experten eine Step-By-Step-Anleitung in ein paar Stichworten aufschreiben?

Ich möchte nicht mit 10 nicht mehr ansprechbaren Rauchmeldern dastehen... (wie ist das eigentlich mit den anderen Devices? Habe auch noch einige Aktoren und Sensoren sonstwo im Haus verteilt.)


Vielen Dank vorab!

Gruß
Matthias

[Hollo]

Ohne es jetzt genau zu wissen, würde ich es einfach mal schrittweise probieren.

- eine VCCU definieren und dieser den vorhandenen HMLAN zuordnen
- einen Rauchmelder von HMLAN auf VCCU als IOGRP (oder wie das heisst, siehe VCCU-Wiki) umstellen
- gucken ob noch alles wie gewünscht geht
- Zusatzfrage wäre dann, ob Dein weiteres IODEV (COC etc) AES kann?

[Otto123]

Ich plane nun, eine VCCU einzurichten, um die Abdeckung mittels eines zweiten IODev (ein vorhandener COC auf einem RPi) zu verbessern. Dabei muss ja irgendwie ein neuer AES-Key in die VCCU, und die existierenden Devices müssen dem neuen Key vertrauen.

Hi,

wieso? Was hat die VCCU primär mit dem System AES Key zu tun? Wenn Du keinen eigenen Key vergeben hast, musst Du gar nichts tun.
Einfach nur die Anleitung beachten und wirklich alles lesen!
http://www.fhemwiki.de/wiki/Virtueller_Controller_VCCU

Wenn Du AES dann eigen konfigurieren willst ist das ein ganz anderes Thema. Und das machst Du dann nur mit der VCCU.

Gruß Otto

[mrichwin]

Hallo zusammen,

vielen Dank für die Antworten! Ich bin einfach mal mutig vorangeschritten, wie empfohlen . VCCU einrichten und den COC (wieder) aktivieren, als zweites IOdevice reinhängen -> der eine neue bisher nicht erreichbare Aktor antwortet sofort. Ich habe dann einfach wie im Wiki beschrieben alle Devices direkt auf die VCCU gehängt.

Die Rauchmelder waren allerdings erstmal nicht mehr erreichbar, wenigstens die, die näher am COC als am HM-CFG-LAN waren ... der COC kann kein AES. Also (vorher waren die Rauchmelder ja auch alle vom HM-CFG-LAN aus erreichbar) die Rauchmelder per

Code Auswählen Erweitern

attr ... IOgrp VCCU:HMLAN1 auf den HM-CFG-LAN "gezwungen", und alles ist wieder gut.

Die Änderung des AES-Key mache ich dann ein anderes Mal...

Schönen Abend in die Runde!
Matthias

[Otto123]

der COC kann kein AES.

Glaub ich nicht: ->https://wiki.fhem.de/wiki/AES_Encryption#I.2FO-Device_.E2.86.90.E2.86.92_Ger.C3.A4t

Für alle CUL-kompatiblen Geräte muss das Perl-Modul Crypt::Rijndael (Debian: libcrypt-rijndael-perl) installiert sein.

Gruß Otto

[mrichwin]

Hallo Otto123,

dafür muss ich in der VCCU einen eigenen Key setzen, und in die Devices übertragen, oder? Da kümmere ich mich am Wochenende mal drum...

Danke & Gruß
Matthias

[Otto123]

dafür muss ich in der VCCU einen eigenen Key setzen, und in die Devices übertragen, oder? Da kümmere ich mich am Wochenende mal drum...

Ich verstehe die Frage nicht. Was hat das wieder mit der Installation von Perl  Modulen für dein CUL Device zu tun?

Wie gesagt AES geht auch erstmal mit dem System internen Key. Allerdings kenne ich mit CUL kompatiblen IOs nicht wirklich aus, außer das sie offenbar nicht unproblematisch sind.

Bitte überprüfe dein System mit hmInfo ob es insgesamt Fehlerfrei läuft, bevor Du mit eigene AES Keys rumspielst.

Gruß Otto