HomeMatic-Forum / FHZ-Forum

Hallo Forum,
ich stelle mir die Frage, wie man sein System wieder zum Laufen bekommt, wenn die CCU eines Tages nicht mehr bootet.
Ich habe mir eine zweite CCU3 gekauft, um im Notfall ein Ersatzteil zu haben. Beide CCUs sind ein Raspberry Pi 3 Model B v2.
Hauptsächlich besteht meine HomeMatic aus HM-Wired Elementen hinter einem DRAP, und wenigen HMIP-Funk Geräten.

Das Forum habe ich natürlich hinreichend durchsucht, finde aber nur Geräte-Tausch-Hinweise mit laufender CCU.
Die einfachste Sache, die SD Karte (oder eine Kopie davon) in eine ander CCU zu stecken funktioniert leider nicht. Da mag es sicherlich lizenztechnische Gründe geben. Auf eine frische, neuinstallierte CCU ein Backup einzuspielen geht leider auch nicht. Machmal sind zwar Programme und Geräte nach dem eingespielten Backup vorhanden (funktionieren jedoch nicht), aber spätestens nach einem Reboot ist alles weg.

Ein weiterer Versuch, die Ersatz-CCU3 mit einem Ersatz-DRAP (alternativ) an den BUS anzuschließen, scheitert daran, dass die Geräte alle auf Werkseinstellung zurückgesetzt werden müssten, bevor sie sich im "neuen" System anmelden lassen.

Ich suche eine Lösung, womit ein Laie auf ein "Ersatzsystem" einfach umschalten kann.

Wie seid ihr auf den "Ernstfall" vorbereitet?

Vielen Dank für eure Beiträge,
ICHzuHAUSE

ICHzuHAUSE hat geschrieben: ↑

12.04.2024, 14:54

Ich habe mir eine zweite CCU3 gekauft, um im Notfall ein Ersatzteil zu haben.

Habe ich auch im Schubfach, und noch diverse andere Ersatzteile (altes Funkmodul, alten Pi etc.)

ICHzuHAUSE hat geschrieben: ↑

12.04.2024, 14:54

Die einfachste Sache, die SD Karte (oder eine Kopie davon) in eine ander CCU zu stecken funktioniert leider nicht.

Bei gleicher Hardwarebasis (Pi) funktioniert das. Gegebenenfalls muss man bei einem anderen Funkmodul das Rekeying für HmIP-Geräte abwaren.

ICHzuHAUSE hat geschrieben: ↑

12.04.2024, 14:54

Da mag es sicherlich lizenztechnische Gründe geben.

Nein, mit der Lizenz hat das nichts zu tun. Es ist die Code-Basis die sich für verschiedene Pi-Generationen etwas unterscheidet, weil schlichtweg andere Prozessoren verwendet werden. Eine SD von einem Pi3 läuft nicht in einem Pi5 und vice versa. Ein eingespieltes Backup auf einem passenden Basissytem läuft aber problemlos.

ICHzuHAUSE hat geschrieben: ↑

12.04.2024, 14:54

Auf eine frische, neuinstallierte CCU ein Backup einzuspielen geht leider auch nicht.

Dann ist bei Dir etwas anderes im Argen, denn genau diese Vorgehensweise ist für diesen Zweck vorgesehen und funktioniert im Allgemeinen problemlos. Allerdings muss man darauf achten, auch die Addons ggf. gemäß der Hardwarebasis zu aktualisieren. In virtualisierten Umgebungen laufen Addons für den Pi ggf. nicht.

ICHzuHAUSE hat geschrieben: ↑

12.04.2024, 14:54

... aber spätestens nach einem Reboot ist alles weg.

Wenn das ein Reboot per Steckerziehen (die sicherste Methode, seine Installation zu beschädigen) ist, dann kann das vorkommen. Bei einem sauberen Restart sollte das nicht passieren, wobei ich wieder bei meiner Bemerkung einen Abschnitt höher wäre. Könnte auch sein, dass Du mit DHCP in Deinem Netz arbeitest und das Austauschgerät eine andere IP erhält und deshalb die Netzwerkkommunikation nicht klappt. Ein Umstieg auf feste IPs (innerhalb des jeweiligen Gerätes konfiguriert, nicht im Router, das ist immer noch DHCP) könnte das Problem lösen.

ICHzuHAUSE hat geschrieben: ↑

12.04.2024, 14:54

Wie seid ihr auf den "Ernstfall" vorbereitet?

Wie oben geschrieben, mit einer Ersatz-CCU und diversen Teilen in der Bastelkiste. Eine Raspberrymatic lässt sich problemlos auf einer neuen SD-Karte aufsetzen und das vorhandene Backup einspielen. Mit der Methode bin ich schon von einer CCU2 auf eine Raspberrymatic auf einem Pi3 und eine Standard-CCU3 und von da wieder auf einen Pi3 mit "neuem" Funkmodul gewechselt. Bis auf das Warten auf Rekeying der funkenden HmIP-Geräte gab es nie Probleme. Firmwareupdates mache ich auch manuell. Wechsel-SD oder ab und zu neue SD-Karte mit einer neuen Firmwareversion bespielen, CCU runterfahren, SD tauschen, booten und Backup einspielen. Somit habe ich auch sichergestellt, dass sich aus meinen Backups lauffähige Systeme wiederherstellen lassen.

Ich persönlich bin kein Freund von virtualisierten CCUs. Gerade weil ich ein lauffähiges System binnen weniger Minuten wieder aus vorhandenen Teilen zusammenbasteln kann, weil es autark läuft und auf wenig zusätzliche Infrastruktur angewiesen ist. Allerdings betreibe ich ein relativ sortenreines System (HM/HmIP und Hue) ohne jegliche Middleware oder Visualisierung. Macht einen schlanken Fuß für solche Problematiken. Je komplexer das System aufgebaut ist, umso komplexer eben auch die möglichen Nebenschauplätze, die man bei einem Hardwareausfall beachten muss.

Gruß Xel66

Vielen Dank für deine schnelle Antwort Xel66

Xel66 hat geschrieben: ↑

12.04.2024, 15:08

Nein, mit der Lizenz hat das nichts zu tun. Es ist die Code-Basis die sich für verschiedene Pi-Generationen etwas unterscheidet, weil schlichtweg andere Prozessoren verwendet werden. Eine SD von einem Pi3 läuft nicht in einem Pi5 und vice versa. Ein eingespieltes Backup auf einem passenden Basissytem läuft aber problemlos.

Das sollte bei mir nicht das Problem sein. In beiden CCUs werkelt ein Broadcom BCM2837...

Xel66 hat geschrieben: ↑

12.04.2024, 15:08

Wenn das ein Reboot per Steckerziehen (die sicherste Methode, seine Installation zu beschädigen) ist, dann kann das vorkommen. Bei einem sauberen Restart sollte das nicht passieren, wobei ich wieder bei meiner Bemerkung einen Abschnitt höher wäre.

Ich fahre immer herunter bevor ich etwas vom Netz trenne. Allerdings kommen Stomausfälle gelegendlich vor, was einem Steckerziehen gleichkommt.

Xel66 hat geschrieben: ↑

12.04.2024, 15:08

Könnte auch sein, dass Du mit DHCP in Deinem Netz arbeitest und das Austauschgerät eine andere IP erhält und deshalb die Netzwerkkommunikation nicht klappt.

Das Austauschgerät hat tatsächlich eine andere (feste) IP. Ich bin davon ausgegangen, dass es "Systemintern" nicht relevant ist.
Hier werde ich zunächst ansetzen. Falls das nicht zum Erfolg führt, gehe ich davon aus, dass meine Backups nicht fehlerfrei sind.

Da du ja schreibst, dass nach dem Einspielen eines Backups alles funktioieren sollte, ist das möglicherweise der Fall. Die SD Karte hatte fehlerhafte Sektoren, ließ sich erst im gefühlt 20ten Versuch kopieren. Mal sehen, ob ich ein uraltes, fehlerfreies Backup finde.

Vielen Dank erst einmal,
ich werde berichten.....

ICHzuHAUSE

ICHzuHAUSE hat geschrieben: ↑

12.04.2024, 16:16

Die SD Karte hatte fehlerhafte Sektoren, ließ sich erst im gefühlt 20ten Versuch kopieren. Mal sehen, ob ich ein uraltes, fehlerfreies Backup finde.

Die SD muss man nicht kopieren. Das ist nicht notwendig und auch nicht zielführend. Über die Systemfunktionen kann man ein Backup erstellen und auf einem Rechner speichern und von da auch wieder einspielen.

Gruß Xel66

Natürlich mache ich Backups über die Systemfunktion. Die werden auch erstellt und können ohne Probleme wieder zurückgespielt werden.

Ich hatte in letzter Zeit immer mehr beobachtet, dass einige Befehle sehr zeitverögert ausgeführt werden. Bei Programmen, die vieles in Bewegung setzen solle (z.B. alle Rollos hoch) blieben ab und zu welche unten. Dieses Forum brachte mich auf die Spur, dass möglicherweise die SD Karte defekt ist. Das ist augenscheinlich auch der Fall.
Das Backupsystem hat offensichtlich das Problem, dass fehlerhafte Daten nicht erkannt und mitkopiert werden. Wie gesagt, die Backups wurden erstellt, und auch das Restoren funktioniert.

Warum die fehlerhaften Backups auf der zweiten CCU nicht laufen, habe ich noch nicht herausbekommen.
Die jetzt gleiche IP hat das Problem nicht lösen können.

Morgen geht es weiter.....

Gruß,
ICHzuHAUSE

ICHzuHAUSE hat geschrieben: ↑

12.04.2024, 19:42

Bei Programmen, die vieles in Bewegung setzen solle (z.B. alle Rollos hoch) blieben ab und zu welche unten.

Daran ist mit relativ hoher Wahrscheinlichkeit kein SD-Defekt die Ursache. Entweder wäre die Datenbank defekt und die Rollladen würden nie fahren (halte ich aber auch eher für unwahrscheinlich, dass dann der Rest funktioniert) oder es sind ganz einfach Timingprobleme durch das erhöhten Funkaufkommen (Kollisionen durch gleichzeitiges Senden/Empfangen der bidirektionalen Kommunikation mehrerer Geräte) die Ursache.

Gruß Xel66

Ich glaube da auch nicht an einen Defekt der SD, klingt nach einer fehlerhaften Programmierung. Auch wenn der DC hochgelaufen ist, reagieren Geräte gar nicht mehr oder verzögert. Aber auch das geschieht nicht ohne Fehler des Anwenders.
Du hast den DC dabei kontrolliert?

Danke für eure Antworten.
Ob die beobachteten Fehler / Verzögerungen der defekten SD Karte zuzuschreiben sind, kann ich natürlich nicht mit Sicherheit sagen. Die SD Karte hat auf jeden Fall Fehler, sonst hätte sie sich ja kopieren lassen. Mein DC ist eigentlich immer unter 5 %.

Meine Annahme, dass die kopierte SD Karte nicht auf der jeweils anderen CCU läuft, ist meiner Ungeduld geschuldet.
Nach dem Booten hat sich zunächst die UI wie gewöhnlich gezeigt. Alarmmeldungen und Servicemeldungen mit grünem Punkt. Ein wenig später kam dann auch noch die Info, dass für 2 Geräte ein FW Update zur Verfügung steht. Also alles schön. Klickt man dann Geräte oder Programme an, dreht nur noch der Wartekringel. Beim Refresh des Browserfensters sind dann Alarmmeldungen und Servicemeldungen grau. Keine Buttons anwählbar, kein Wartekringel. So, und hier kam meine Ungeduld ins Spiel. Gewöhnlich habe ich hier abgebrochen.
Einmal jedoch nicht, da habe ich es einfach weiterlaufen lassen. Nach ca. 20 Minuten hatte sich die CCU gesammelt und alles lief, wie es soll.

Daraufhin habe ich ein CCU FW Update gemacht. Nachdem dieser abgeschlossen war, konnte die CCU alle Ausgänge steuern, der Neo-Server ging auch. Nur die Inputs funktionierten nicht und die Zustände der Ausgänge wurden fehlerhaft angezeigt. Nach einem Reboot war dann aber alles okay.

Heute konnte ich beobachten, dass das lange Booten nachdem ich von einer CCU auf die andere wechsle, nur passiert, wenn der DRAP zwischendurch nicht stromlos ist. Wenn man das beachtet, kann man jetzt ganz normal mit der einen oder anderen CCU Booten und die HomeMatic betreiben.

Somit habe ich mein Ziel erreicht. Was schön gewesen wäre, wenn auch der DRAP mit meinem Ersatz-DRAP per Schalter ausgetauscht werden könnte. Da sehe ich aber keine Möglichkeit das zu realisieren.

Vielen Dank für eure Hilfe.
Schönes Wochenende wünscht
ICHzuHAUSE

Hi!

Einen DRAP zu tausche ist nun wahrlich kein Problem.
Alten DRAP ablernen, neuen anlernen und anstelle des alten DRAPs in der UV anklemmen.
Dauert alles zusammen keine 5 Minuten.

Gruß,
Gerti

Hallo!

Gerti hat geschrieben: ↑

14.04.2024, 08:27

Einen DRAP zu tausche ist nun wahrlich kein Problem.
Alten DRAP ablernen, neuen anlernen und anstelle des alten DRAPs in der UV anklemmen.

Rein aus Interesse (hab nichts wired): was ist, wenn der DRAP so tot ist, dass man ihn nicht mehr ablernen kann?
Trotzdem nur DRAP austauschen und weitermachen, oder müssen dann die wired-Geräte resettet und an den neuen DRAP angelernt werden?


Roland