Systemwechsel: HmIP + neue piVCCU3 = geht nicht mehr

[galegro]

Aufgrund eines Betriebssystemwechsels (Buster -> Bullseye) mussten diverse Homematic Geräte mit umziehen. Hierzu habe ich ein Backup vom alten System in das neue eingespielt.

Alle klassischen Homematic Geräte arbeiten einwandfrei, die HmIP Geräte melden bloß „Gerätekommunikation gestört“. Eine Anfrage bei ELV wurde abgebügelt, weil ich keine originale CCU(3) verwende.

Liegt das wirklich an deiner piVCCU3, die seit über ein Jahr mir beste Dienste leistet? Was kann ich ggf. tun, um die HmIP Gerät auch im neuen piVCCU3 System zur Zusammenarbeit zu bewegen?

[alexreinert]

Wurde auch das Funkmodul getauscht? Welches Funkmodul ist im Einsatz? Welche Hardware wird verwendet? Was liefert pivccu-info?

[galegro]

Ich habe ein identisches System aufgebaut aus Raspberry Pi 4 und RPF-RF-MOD.

Weil obiger Fehler auftrat, habe ich bei einem zweiten Versuch das Funkmodul aus dem alten System übernommen. Der Fehler blieb.

Es war stets nur ein System in Betrieb.

Wo finde ich pivccu-info?

[alexreinert]

Raspberry Pi 4 ist ein massiver Störsender auf 868Mhz und stört vor allem die HmIP Kommunikation. Hier hilft es regelmäßig nur das gesamte Funkmodul mind 1m abzusetzen z.B. per HB-RF-USB.

[galegro]

Vorab erstmal herzlichen Dank für deine prompte Hilfe!

Der Raspberry Pi ist in einem Aluminiumgehäuse eingeschlossen. Die gesamte Installation mit Dutzenden Homematic Geräten läuft in dieser Anordnung rund zwei Jahre völlig störungsfrei.

Warum also nach diesem Systemwechsel nur bei HmIP diese Fehler?

Die klassischen Geräte betreibe ich ohne „Sicherheitsschlüssel“. Bei HmIP hat man ja diesbezüglich keine Kontrolle; hier läuft die Kommunikation ja immer gesichert ab.

Was verursacht diesen Fehler? Koppeln sich die piVCCU3 und die HmIP Geräte, indem sie ggf. einen Schlüssel austauschen?

Gehe ich auf das alte System zurück, funktionieren alle HmIP Geräte wieder problemlos.

Im Prinzip mache ich doch nichts Anderes, was man auch tut, wenn man eine defekte CCU tauschen muss.

[alexreinert]

Vermutlich hattest du bisher einfach Glück. Aber es ist nachgewiesener Fakt, dass der Pi 4 HmIP massiv stört und wenn ich dann höre, dass du den Pi zusammen mit dem Funkmodul in ein Metallgehäuse steckst, dann liegt das Problem einfach mit hoher Wahrscheinlichkeit daran.

[galegro]

Nein, nein, nein, .. ;-) Weder hatte ich Glück, noch steckt das Funktmodul im Gehäuse (Argon ONE), auch habe ich alle Komponenten mittlerweile schon einmal untereinander getauscht.

Nicht Glück, sondern das Gehäuse dürfte erfolgreich all die Jahre dafür gesorgt haben, dass eben der Raspberry Pi 4 nicht sein Unwesen treiben konnte.

Sollten wir daher nicht der Frage nachgehen, ob sich die piVCCU und die HmIP Geräte in irgendeiner Weise (ggf. durch Austausch eines Schlüssels?) koppeln?

Ich habe den Befehl "pivccu3-info" gefunden. Ich fahre morgen früh einmal das alte System herunter und starte das neue. Anschließend melde ich ich mit den Infos. Jetzt am Abend laufen einige Skripte, die ich nicht stören will.

[alexreinert]

Die keys hängen bei HmIP im Funkmodul. Wenn du das Funkmodul wechselst, wird im Closed Source von eQ-3 ein Rekeying gemacht, wenn du das Funkmodul vom alten System mitnimmst, braucht es das nicht und in dem Fall liegen Kommunikationsstörungen entweder an einem komplett nicht erkannten Funkmodul oder an Funkstörungen und bis jetzt ist jedes Mal, wenn solche Probleme berichtet wurden, die Lösung gewesen, einen Meter Luft zwischen Pi und Funkmodul zu schaffen.

[galegro]

Das habe ich befürchtet und verstanden und bin damit einen wichtigen Schritt weiter, weiß ich nun endlich, was sich da so alles abspielt.

Wie kann ich die Kopplung zwischen Funkmodul und HmIP Geräten aufbrechen oder dafür sorgen, dass ein „rekeying“ angestoßen wird?

[alexreinert]

Das passiert automatisch beim Restart nach dem Einspielen des Backups bzw. beim ersten Start mit neuem Funkmodul und kann nicht manuell angestoßen werden.

[galegro]

Mit deinen Hinweis hinsichtlich "Rekeying" konnte ich nun weitere Tests durchführen.

1) altes Funkmodul in neues System: Der Fehler ist unverändert vorhanden. Nur die klassischen Homematic Geräte sind bedienbar. 2) neues Funkmodul in altes System: Der Fehler tritt nicht auf. Das System ist unmittelbar nach dem Neustart in allen Komponenten funktionsfähig.

Nun verfüge ich natürlich nicht über deine Erfahrungen. Ich bin verwirrt. Meine Gedanken ..

Ich hätte jetzt daraus den Verdacht geschöpft, dass die Schlüssel (Rekeying) am Ende doch nicht im Funkmodul abgelegt sein könnten; schließlich dürfte so ein "Rekeying" eine gewisse Zeit benötigen. Aber wenn du dessen sicher bist, muss ich wohl weitersuchen. Auch könnte es nun noch immer sein, dass der neue Raspberry Pi4 ein anderes Störpotential besitzt als der alte. Nun überlege ich, wie ich das herausfinden kann. Über entsprechende Messgeräte verfüge ich nicht. Meine erste Idee: Ich übertrage das Backup des neuen Systems auf das alte und schaue nach, ob's dort funktioniert.

Jedenfalls sollten wir sicher schließen können, dass das neue Funkmodul nicht defekt ist.

[alexreinert]

Ich wiederhole: Abstand zwischen Funkmodul und Pi.

[galegro]

Das habe ich schon verstanden. ;-)

Um die Problematik wissend, dass der Raspberry Pi 4 ein schlimmer Störenfried sein kann, habe ich ihn über Jahre erfolgreich eingesperrt (Faraday’scher Käfig). Diese Anordnung funktioniert nun schon mehr als zwei Jahre zu meiner vollsten Zufriedenheit. So frage ich, warum das nicht auch weiterhin möglich sein sollte.

Da ich bei meinen Gegebenheiten deinen Vorschlag nicht ohne Weiteres realisieren kann, muss ich halt versuchen, dem Problem anderweitig zu Leibe zu rücken. ;-( Denn wie sollte ich das RPF-RF-MOD anschließen?

Wie lange dauert erfahrungsgemäß so ein Rekeying. Ist das mit dem Booten des Systems sozusagen bereits abgeschlossen?

Ich werde meinen oben beschriebenen Test durchführen und berichten.

[alexreinert]

Je nach Menge an Geräten geht das Rekeying zwischen Sekunden und Stunden. Das Gehäuse ist kein faradayischer Käfig, nur der Deckel ist aus Aluminium und der hat ja auch noch Löcher z.B. für die GPIOs.

[galegro]

Herzlichen Dank für deine tatkräftige Unterstützung. Langsam lichtet sich dank deiner Hilfe das Dunkel.

Nach vielem Hin und Her (Tauschen der Komponenten, Software, ..) sieht es danach aus, dass ich eine funktionierende Installation zusammenstellen konnte.

Hier mein (letztes) Vorgehen: Ich habe auf das neue System (Bullseye 64 Bit) mittels BackItUp ein Backup des alten Systems (Buster 32 Bit) eingespielt. Nach einigen Anpassungen lief alles - eben bis auf die HmIP Geräte. Nun habe ich ein mittels ApplePiBaker erstelltes Backup meines neuen Systems (Bullseye 64 Bit) verwendet, und das alte System mit dieser neuen Software/Konfiguration bestückt. Resultat: Bis auf einen störrischen HmIP-BSM läuft nur alles wie gewünscht.

Hinsichtlich der Ursachenanalyse bin ich noch nicht sehr weit gekommen. Da stehen noch einige Tests aus. Ich werde berichten.

[mulder999]

Check my comment here: https://github.com/jens-maus/RaspberryMatic/discussions/1883#discussioncomment-3438050

Update of the kernel is always a nightmare. Rebooting, then reinstalling the pivccu* packages is necessary as soon as it goes bad. Following my exact steps should normally help reverting to working behavior.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.