Vereinfachte Proxmox Installationsroutine

[norbert]

Hi,

ich habe hier seit Einzug eine CCU3 laufen und dort nahezu ausschließlich HmIPW-Geräte im System, die über den DRAP eingebunden sind. Da ich jetzt nach und nach alle Systeme auf eine Proxmox-Instanz verschieben möchte, ist jetzt auch die CCU3 dran.

Also, Backup gemacht, CCU3 heruntergefahren, HmIP-RFUSB (FW 4.4.18) an NUC angeschlossen, Proxmox-Script ausgeführt, VM gestartet, Stick wurde erkannt und wird in der VM erkannt. Sehr schön.

DANN: Backup einspielen, die VM startet neu, HmIP-RFUSB wird wieder erkannt und kann eingebunden werden. HmIP Geräte können angelernt werden (hab das mit einem Fensterkontakt getestet)... ABER...

Wie bekomme ich den DRAP ins System? Die Geräte werden zwar alle angezeigt, doch ohne Werte. Bei Einstellungen - Geräte wird in der Spalte RSSI gelb hinterlegt "config" angezeigt.

Offenbar findet zwischen DRAP und Raspberrymatic keine Verbindung statt. Was habe ich übersehen?

[Roland M.]

Hallo!

Wie bekomme ich den DRAP ins System? Die Geräte werden zwar alle angezeigt, doch ohne Werte. Bei Einstellungen - Geräte wird in der Spalte RSSI gelb hinterlegt "config" angezeigt.

Rekeying abgewartet?
Kann je nach Umfang deiner Installation und Auslastung der eQ-3-Server ein paar Stunden dauern...


Roland

[jp112sdl]

Rekeying abgewartet?
Kann je nach Umfang deiner Installation und Auslastung der eQ-3-Server ein paar Stunden dauern...

Die Mythbuster sind an der Sache dran, den Mythos, den eQ-3 Server als Ursache für teilweise lange Wartezeiten nach einem Funkmodultausch vorzuschieben, auszuräumen.

Wenn man die Online-Anfrage mal mit einer validen (hier im Beispiel für die Übersichtlichkeit eingekürzten) Payload durchspielt, kam ich bisher noch nie auf Antwortzeiten von > 1 Sekunde.

Code: Alles auswählen

time curl -d '{protocolVersion":1,"accessPointID":"30150377DC00...joiningDeviceFirmwareVersion":0}}' -H "Content-Type: application/json" -X POST https://secgtw.homematic.com:8443/ccm/gateway

{"jdEncNWK":"ED71B95DF7C1D47A0...B5EF4A319C8442637"}
real    0m0,094s
user    0m0,008s
sys     0m0,008s

Desweiteren steht die Frage im Raum, ob denn der Schlüssel für jedes angelernte Gerät online ausgetauscht wird, oder nur für das Funkmodul...
to be continued

[jmaus]

Rekeying abgewartet?
Kann je nach Umfang deiner Installation und Auslastung der eQ-3-Server ein paar Stunden dauern...

Die Mythbuster sind an der Sache dran, den Mythos, den eQ-3 Server als Ursache für teilweise lange Wartezeiten nach einem Funkmodultausch vorzuschieben, auszuräumen.

Wenn man die Online-Anfrage mal mit einer validen (hier im Beispiel für die Übersichtlichkeit eingekürzten) Payload durchspielt, kam ich bisher noch nie auf Antwortzeiten von > 1 Sekunde.

Code: Alles auswählen

time curl -d '{protocolVersion":1,"accessPointID":"30150377DC00...joiningDeviceFirmwareVersion":0}}' -H "Content-Type: application/json" -X POST https://secgtw.homematic.com:8443/ccm/gateway

{"jdEncNWK":"ED71B95DF7C1D47A0...B5EF4A319C8442637"}
real    0m0,094s
user    0m0,008s
sys     0m0,008s

Find ich super das du dir das so genau anschaust. Hoffe damit finden wir raus wo es denn wirklich hängt am Schluss.

Desweiteren steht die Frage im Raum, ob denn der Schlüssel für jedes angelernte Gerät online ausgetauscht wird, oder nur für das Funkmodul...
to be continued

Meines Wissens nur für das Funkmodul. So zumindest meine latest Info nachdem ich bei eQ3 tiefer nachgefragt hatte warum das rekeying manchmal so lange dauern kann und man das nicht lokal auf der CCU ablaufen lassen kann. Problem ist wohl das der Root-Key des Funkmodules selbst nur auf dem server da bekannt ist und man den aber für das Rekeying braucht.

Warum allerdings das ganze Rekeying (wo es doch nur um das Funkmodul geht) so lange dauern kann konnte mir auch keiner erklären und konnte man auch nicht nachvollziehen. Deshalb kannst du gerne weiter selbst forschen und vielleicht finden wir ja mal wieder irgendeinen Bug/Problem im HMIPServer der das Problem dann wie von Geisterhand beseitigt. Wäre ja nicht das 1. mal.

[jp112sdl]

Warum allerdings das ganze Rekeying (wo es doch nur um das Funkmodul geht) so lange dauern kann konnte mir auch keiner erklären und konnte man auch nicht nachvollziehen

Als wir, Baxxy und ich, uns mit dem >>>Offline-Rekeying<<< beschäftigt hatten, kam es auch vor, dass Geräte nach dem Funkmodultausch nicht mehr ansprechbar waren und erst nach einer Re-Inclusion (lokaler Werkreset) wieder funktionierten.

Nun hat es den Anschein, dass das wohl gar nichts mit dem lokalen Key-Exchange zu tun hatte.

Rein logisch wird auf Seite der CCU beim FuMo-Tausch nur die SGTIN in allen .dev-Dateien ausgetauscht.
Und auch die RF-Adresse, mit der physisch gefunkt wird, bleibt wie bei BidCos die selbe (steht in der hmip_address.conf).

Ich hatte zwischenzeitlich mal mit dem AskSinAnalyzer geschaut sehen können, dass beim Erstkontakt mit einem Gerät nach dem FuMo-Tausch zig Telegramme übertragen werden. Was da inhaltlich passiert, kann ich leider nicht interpretieren.
Aber irgendwie scheint es noch einen Unterschied zu geben, ob ich den OC8 über "Status und Bedienung" schalte oder über eine verknüpfte virtuelle HmIP-CCU-Taste.

Naja, Jugend forscht... auch noch Ü40

[jmaus]

Warum allerdings das ganze Rekeying (wo es doch nur um das Funkmodul geht) so lange dauern kann konnte mir auch keiner erklären und konnte man auch nicht nachvollziehen

Als wir, Baxxy und ich, uns mit dem >>>Offline-Rekeying<<< beschäftigt hatten ...

Oh, dieser Beitrag ging leider komplett an mir vorbei Hab gerade aber mal dort noch einen Hinweis bzw. eine Frage gepostet. Aber hier schon einmal vielen Dank dafür das ihr euch das mit dem Offline-Rekeying selbst noch einmal angeschauen hattet.

Ich hatte zwischenzeitlich mal mit dem AskSinAnalyzer geschaut sehen können, dass beim Erstkontakt mit einem Gerät nach dem FuMo-Tausch zig Telegramme übertragen werden. Was da inhaltlich passiert, kann ich leider nicht interpretieren.
Aber irgendwie scheint es noch einen Unterschied zu geben, ob ich den OC8 über "Status und Bedienung" schalte oder über eine verknüpfte virtuelle HmIP-CCU-Taste.

Meines Wissen wird so den Geräten eben die neue Funkadresse ihres neuen Ansprechpartners (d.h. des Funkmodules) mitgeteilt. Vielleicht sogar eben so auch der neue berechnete lokale Key des Funkmodules. Aber mit bestimmtheit kann ich das auch nicht sagen. Es bleibt aber trotzdem natürlich etwas verwunderlich, das – wenn wirklich nur der Key des Funkmodules selbst neu berechnet werden muss - das Re-keying nicht immer sauber und smooth durchgeht und manchmal wohl es zu Geräten kommt mit denen keine Kommunikation mehr möglich ist. Selbst hatte ich das zwar noch nie, aber wäre schon interessant herauszufinden woher das genau kommt wenn denn das Online-Rekeying zum secgtw von eQ3 eigentlich schon schnell und unproblematisch von statten geht....

[jp112sdl]

Meines Wissen wird so den Geräten eben die neue Funkadresse ihres neuen Ansprechpartners (d.h. des Funkmodules) mitgeteilt.

Die Adresse, mit der gefunkt wird, bleibt immer die selbe. Die wird aus der hmip_address.conf gezogen.

Nur die Seriennummer des zugeordneten Funkmoduls wird in den .dev-Dateien ausgetauscht.

das Re-keying nicht immer sauber und smooth durchgeht und manchmal wohl es zu Geräten kommt mit denen keine Kommunikation mehr möglich ist.

Für mich ist fraglich, wie das bei Sensoren und Fernbedienung, bzw. allen Geräten, die nicht bedient werden, abläuft.

Das Gerät meldet sich irgendwann mal wieder und sendet seine Payload verschlüsselt mit dem alten Schlüssel.

Der HMIPServer muss das erkennen und dem Gerät dann den Schlüsselaustausch anbieten... irgendwo klemmt es da dann wohl manchmal

[norbert]

Rekeying ist wohl das Stichwort. Mensch, da findet man zig Anleitungen im Internet über den Umstieg, aber davon war nie die Rede. Jetzt sucht man hier im Forum und da wundert man sich über nichts mehr.
Nein, ich habe tatsächlich nicht lange gewartet, 30-60 Minuten vielleicht. Wenn das System am nächsten Tag nicht gehen sollte, schimpft meine Frau wieder über die blöde Technik. Das hat mich wohl etwas gestresst

Ich wollte den Beitrag hier auch nicht in eine andere Richtung führen, sorry. Das Script funktioniert ja, und darum geht es hier. Ich teste es gleich noch einmal und warte...

15 Stunden später, keine Änderung. Nochmal die Sicherung des HmIPW-Netzteils rausmachen, reinmachen, nachsehen: Alle Geräte sind nach und nach ansprechbar. Prima! Es lief dann wohl doch etwas in der Nacht ab.
Vielen Dank euch allen für die Arbeit, die ihr euch (ge)macht (habt)!

[mape]

Hallo,

ich habe auf meine Frage leider noch keine Antwort gefunden:
Ich betreibe aktuell einen RPI2 mit rasperrymatic und dem HM-MOD-RPI-PCB, möchte aber auf einen PI4 mit pimox umsteigen.
Kann ich den HM-MOD-RPI-PCB dafür verwenden, oder benötigt es da zwingend ein USB oder ETH Device?

Danke!

Gruß,
Markus

[Baxxy]

einen PI4 mit pimox

Wie gedenkst du denn dort RaspberryMatic zu betreiben?
Eine native RaspberryMatic-VM für Pimox gibt es leider nicht.

Bleibt also nur RM als Docker innerhalb des Pimox-Host-OS.
Da sollte das nach Anleitung mit einem GPIO-Funkmodul gehen.

Oder eine (z.B. Debian-)VM auf der dann RM als Docker läuft. Hier ist mir kein Weg bekannt ein GPIO-Funkmodul auf der Host-Hardware an die VM und in den Container "durchzuleiten".