Vorgehensweise bei der Migration CCU1 -> CCU2 OHNE Backup
Moderator: Co-Administratoren
-
- Beiträge: 2
- Registriert: 20.11.2017, 17:25
Vorgehensweise bei der Migration CCU1 -> CCU2 OHNE Backup
Hallo.
Ich habe eine CCU1 (letzte Firmwareversion), bei der das Generieren einer Backupdatei anscheinend irgendetwas schief geht! Weder das Zurückspielen des Backups auf die CCU1, noch auf eine neu aufgesetzte RaspberryMatic klappt. Der Sicherheitsschlüssel wird beim Zurückspielen nicht akzeptiert.
Verify:
Ich habe die Konfigurationsdatei keys in config-Ordner der CCU1 ausgelesen und den MD5-Wert mittels eines MD5-Generators und aktuellem Sicherheitsschlüssel generiert und verglichen: kein Unterschied!
=> Fehler beim Erzeugen der Backup-Datei?! (Backup-Erstellung ohne Fehlermeldung generiert und per Browser abgespeichert)
Nun meine Frage:
Was wird beim Einspielen eines Backups auf der RaspberryMatic alles durchgeführt, um dies manuell nachzustellen?
Da ich vollen Zugriff auf CCU1 und CCU2 habe, kann ich sowohl rfKey als auch centralAddress kopieren, danach auch die dev-Dateien im rfd-Verzeichnis und hs485d.
Die Geräte habe ich zwar im Geräte-Eingang der CCU2 (Test im Geräte-Eingang funktioniert auch), aber nachdem sie übernommen wurden, klappt die Kommunikation mit den HM-BidCos-Geräten nicht (nach Connect-Versuch rotes Signal für wenige Sekunden).
Der erste und wichtigste Schritt wäre schon geschafft, wenn alle BidCos-Geräte ohne Ablernen inkl. Werksreset an CCU1 + erneutes Anlernen an CCU2 funktionsfähig wären!
Ich habe eine CCU1 (letzte Firmwareversion), bei der das Generieren einer Backupdatei anscheinend irgendetwas schief geht! Weder das Zurückspielen des Backups auf die CCU1, noch auf eine neu aufgesetzte RaspberryMatic klappt. Der Sicherheitsschlüssel wird beim Zurückspielen nicht akzeptiert.
Verify:
Ich habe die Konfigurationsdatei keys in config-Ordner der CCU1 ausgelesen und den MD5-Wert mittels eines MD5-Generators und aktuellem Sicherheitsschlüssel generiert und verglichen: kein Unterschied!
=> Fehler beim Erzeugen der Backup-Datei?! (Backup-Erstellung ohne Fehlermeldung generiert und per Browser abgespeichert)
Nun meine Frage:
Was wird beim Einspielen eines Backups auf der RaspberryMatic alles durchgeführt, um dies manuell nachzustellen?
Da ich vollen Zugriff auf CCU1 und CCU2 habe, kann ich sowohl rfKey als auch centralAddress kopieren, danach auch die dev-Dateien im rfd-Verzeichnis und hs485d.
Die Geräte habe ich zwar im Geräte-Eingang der CCU2 (Test im Geräte-Eingang funktioniert auch), aber nachdem sie übernommen wurden, klappt die Kommunikation mit den HM-BidCos-Geräten nicht (nach Connect-Versuch rotes Signal für wenige Sekunden).
Der erste und wichtigste Schritt wäre schon geschafft, wenn alle BidCos-Geräte ohne Ablernen inkl. Werksreset an CCU1 + erneutes Anlernen an CCU2 funktionsfähig wären!
Zuletzt geändert von smartdeveloper am 24.11.2017, 11:12, insgesamt 1-mal geändert.
- anli
- Beiträge: 4326
- Registriert: 10.06.2009, 14:01
- Wohnort: 20 Min. nördlich von Hannover und bei Bremen
- Hat sich bedankt: 1 Mal
- Danksagung erhalten: 23 Mal
- Kontaktdaten:
Re: Vorgehensweise bei der Migration CCU1 -> CCU2 OHNE Backu
Hallo und herzlich willkommen Andreas,
ich würde den Ordner /usr/local bei fertig geschriebener homematic.regadom aus der CCU1 nehmen und auf die CCU2 "spielen", zum Beispiel per SSH.
Hast Du Sonderzeichen im Sicherheitsschlüssel? Manche Versionen zickten damit rum, besonders mit & und ! kam es zu Problemen, dann war der Key nur der Teil bis zum Sonderzeichen. Würde allerdings nicht erklären, warum die MD5 übereinstimmen.
ich würde den Ordner /usr/local bei fertig geschriebener homematic.regadom aus der CCU1 nehmen und auf die CCU2 "spielen", zum Beispiel per SSH.
Hast Du Sonderzeichen im Sicherheitsschlüssel? Manche Versionen zickten damit rum, besonders mit & und ! kam es zu Problemen, dann war der Key nur der Teil bis zum Sonderzeichen. Würde allerdings nicht erklären, warum die MD5 übereinstimmen.
Herzliche Grüße, anli
Alle Angaben ohne Gewähr und Haftung meinerseits. Verwendung der von mir zur Verfügung gestellten Downloads auf eigene Gefahr. Ich bitte um Verständnis, dass ich aus zeitlichen Gründen keine unaufgeforderte Hilfestellung per PN/Mail geben kann. Bitte allgemeine Fragen ins Forum stellen, hier können viele fähige User viel schneller helfen.
Homematic-Manager v2: einfaches Tool zum Erstellen von Direktverknüpfungen und Bearbeiten von Gerätenamen, -parametern etc. für Homematic und HomematicIP (Alternative diesbzgl. zur WebUI)
Einsteiger-Hilfe • erweiterter Skript-Parser
Alle Angaben ohne Gewähr und Haftung meinerseits. Verwendung der von mir zur Verfügung gestellten Downloads auf eigene Gefahr. Ich bitte um Verständnis, dass ich aus zeitlichen Gründen keine unaufgeforderte Hilfestellung per PN/Mail geben kann. Bitte allgemeine Fragen ins Forum stellen, hier können viele fähige User viel schneller helfen.
Homematic-Manager v2: einfaches Tool zum Erstellen von Direktverknüpfungen und Bearbeiten von Gerätenamen, -parametern etc. für Homematic und HomematicIP (Alternative diesbzgl. zur WebUI)
Einsteiger-Hilfe • erweiterter Skript-Parser
- Roland M.
- Beiträge: 9805
- Registriert: 08.12.2012, 15:53
- System: CCU
- Wohnort: Graz, Österreich
- Hat sich bedankt: 252 Mal
- Danksagung erhalten: 1381 Mal
Re: Vorgehensweise bei der Migration CCU1 -> CCU2 OHNE Backu
Hallo und willkommen auch von mir!
Dabei kannst du ja gemütlich vorgehen und je nach verfügbarer Zeit einzelne Räume, Gewerke oder einfach sinnvolle Gruppen übersiedeln.
Ich bin (bei damals etwa 40 Geräten) so vorgegangen und habe es nicht bereut! Man glaubt kaum, welcher programmtechnische Schrott sich innerhalb kurzer Zeit ansammelt!
Ganz abgesehen von der eigenen Lernkurve, wenn man durch neues Wissen heute ein Problem viel eleganter und einfacher lösen könnte.
Roland
Auch wenn du das vermutlich nicht hören willst, ich würde die Gelegenheit nutzen um die gesamte Installation auf der CCU2 sauber neu anzulegen!smartdeveloper hat geschrieben:Der erste und wichtigste Schritt wäre schon geschafft, wenn alle BidCos-Geräte ohne Ablernen inkl. Werksreset an CCU1 + erneutes Anlernen an CCU2 funktionsfähig wären
Dabei kannst du ja gemütlich vorgehen und je nach verfügbarer Zeit einzelne Räume, Gewerke oder einfach sinnvolle Gruppen übersiedeln.
Ich bin (bei damals etwa 40 Geräten) so vorgegangen und habe es nicht bereut! Man glaubt kaum, welcher programmtechnische Schrott sich innerhalb kurzer Zeit ansammelt!
Ganz abgesehen von der eigenen Lernkurve, wenn man durch neues Wissen heute ein Problem viel eleganter und einfacher lösen könnte.
Roland
Zur leichteren Hilfestellung bitte unbedingt beachten:
-----------------------------------------------------------------------
1. CCU2 mit ~100 Geräten (in Umstellung auf RaspberryMatic-OVA auf Proxmox-Server)
2. CCU2 per VPN mit ~50 Geräten (geplant: RaspberryMatic auf Charly)
3. CCU2 per VPN mit ~40 Geräten (geplant: RaspberryMatic auf CCU3)
CCU1, Test-CCU2, Raspi 1 mit kleinem Funkmodul, RaspberryMatic als VM unter Proxmox, Access Point,...
- Bezeichnung (HM-... bzw. HmIP-...) der betroffenen Geräte angeben (nicht Artikelnummer)
- Kurzbeschreibung des Soll-Zustandes (Was soll erreicht werden?)
- Kurzbeschreibung des Ist-Zustandes (Was funktioniert nicht?)
- Fehlermeldungen genau abschreiben, besser noch...
- Screenshots von Programmen, Geräteeinstellungen und Fehlermeldungen (direkt als jpg/png) einstellen!
-----------------------------------------------------------------------
1. CCU2 mit ~100 Geräten (in Umstellung auf RaspberryMatic-OVA auf Proxmox-Server)
2. CCU2 per VPN mit ~50 Geräten (geplant: RaspberryMatic auf Charly)
3. CCU2 per VPN mit ~40 Geräten (geplant: RaspberryMatic auf CCU3)
CCU1, Test-CCU2, Raspi 1 mit kleinem Funkmodul, RaspberryMatic als VM unter Proxmox, Access Point,...
-
- Beiträge: 4155
- Registriert: 09.09.2012, 10:41
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 78 Mal
- Danksagung erhalten: 301 Mal
Re: Vorgehensweise bei der Migration CCU1 -> CCU2 OHNE Backu
Das kann ich hundertprozentig unterschreiben. Habe ich genauso gemacht. Man glaubt nicht, auf was für Leichen und Mist man dabei stößt.Roland M. hat geschrieben: Auch wenn du das vermutlich nicht hören willst, ich würde die Gelegenheit nutzen um die gesamte Installation auf der CCU2 sauber neu anzulegen!...
Ich muss allerdings gestehen, dass mir meine ioBroker-Installation bei der Migration sehr geholfen hat. So konnte ich manche Zustände (z.B. Systemvariablen) zwischen den beiden CCUs spiegeln.
Gruß
Manfred
Es gibt 10 Arten von Menschen: solche die Binärcode verstehen und solche, die ihn nicht verstehen.
- Black
- Beiträge: 5483
- Registriert: 12.09.2015, 22:31
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Wegberg
- Hat sich bedankt: 424 Mal
- Danksagung erhalten: 1074 Mal
- Kontaktdaten:
Re: Vorgehensweise bei der Migration CCU1 -> CCU2 OHNE Backu
kann ich auch bestätigen.
ich hab auch das beil genommen beim umzug auf die raspberrymatic und mich von alten zöpfen verabschiedet. in 2 jahren, kam alleine durch die lernkurve, viel Müll zusammen.
Bei der Migration hat mit auch IOBroker gut mitgeholfen, währen der Umzugszeit waren 2 rega instanzen und diverse rpc instanzen beider CCU´s zu managen. aber es Klappe gut.
wobei der Kollege noch das problem des Sicherheitsschlüssels hat... er müsste da eigentlich die geräte ja mit werksreset sauber von der ccu1 ablernen.
Gruss, Black
ich hab auch das beil genommen beim umzug auf die raspberrymatic und mich von alten zöpfen verabschiedet. in 2 jahren, kam alleine durch die lernkurve, viel Müll zusammen.
Bei der Migration hat mit auch IOBroker gut mitgeholfen, währen der Umzugszeit waren 2 rega instanzen und diverse rpc instanzen beider CCU´s zu managen. aber es Klappe gut.
wobei der Kollege noch das problem des Sicherheitsschlüssels hat... er müsste da eigentlich die geräte ja mit werksreset sauber von der ccu1 ablernen.
Gruss, Black
Wenn das Fernsehprogramm immer mehr durch nervende Werbung unterbrochen wird und der Radiomoderator nur noch Müll erzählt, ist es besser, die Zeit für sinnvolle Dinge zu nutzen -
mal aufs Klo zu gehen, ein Bier zu holen oder einfach mal den roten AUS-Knopf zu drücken. Klick - und weg
Script Time Scheduler V1.3
AstroSteuerung über Zeitmodul flexibel mit Offset / spätestens, frühestens
SDV 5.03.01 Das umfassende Entwicklungs und Diagnosetool für Homematik
Selektive Backups - Nützliche Dinge, die die WebUI nicht kann
Intel NUC6 Celeron 16GB mit 512GB SSD unter Proxxmox mit insgesamt 5 VM: 2 x bloatwarebefreiter Raspberrymatik, 2 x IOBroker als Middleware und einer MariaDB zur Archivierung. Verbrauch: 6W
technical contribution against annoying advertising
mal aufs Klo zu gehen, ein Bier zu holen oder einfach mal den roten AUS-Knopf zu drücken. Klick - und weg
Script Time Scheduler V1.3
AstroSteuerung über Zeitmodul flexibel mit Offset / spätestens, frühestens
SDV 5.03.01 Das umfassende Entwicklungs und Diagnosetool für Homematik
Selektive Backups - Nützliche Dinge, die die WebUI nicht kann
Intel NUC6 Celeron 16GB mit 512GB SSD unter Proxxmox mit insgesamt 5 VM: 2 x bloatwarebefreiter Raspberrymatik, 2 x IOBroker als Middleware und einer MariaDB zur Archivierung. Verbrauch: 6W
technical contribution against annoying advertising
-
- Beiträge: 4155
- Registriert: 09.09.2012, 10:41
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 78 Mal
- Danksagung erhalten: 301 Mal
Re: Vorgehensweise bei der Migration CCU1 -> CCU2 OHNE Backu
Ein Grund mehr, den steinigen Weg zu wählen.Black hat geschrieben:wobei der Kollege noch das problem des Sicherheitsschlüssels hat... er müsste da eigentlich die geräte ja mit werksreset sauber von der ccu1 ablernen.
Es gibt 10 Arten von Menschen: solche die Binärcode verstehen und solche, die ihn nicht verstehen.
-
- Beiträge: 2
- Registriert: 20.11.2017, 17:25
Re: Vorgehensweise bei der Migration CCU1 -> CCU2 OHNE Backu
Hallo anli,
besten Dank für Deine Antwort.
Meine Frage @all:
Hat dies schon jemand durchgeführt und musste danach noch nachkorrigiert werden? Gibt es Nebeneffekte mit "Gesichert"en BisCos-Geräten?
@all: Danke für Eure Kommentare.
Den Weg von ca. 50 BidCos-Geräten neu anzulernen hatte ich vor ca. zwei Jahren. Ein Cleaning hatte ich also schon .
Bei der Konzeption vor einigen Jahren war mir noch nicht bewusst, dass ein Anlernen eines HM-Gerätes nicht eine einmalige Sache ist. Beispielsweise sind meine HM-LC-Bl1-FM Jalousie-Aktoren ohne (!) Bedienungsschalter für Auf/Ab fest eingebaut. Für ein Neuanlernen muss ich also alle Aktoren temporär mit Schalter per 230V verdrahten. Anscheinend hat eQ3 dazugelernt und das Starten des Anlernmodus des Homematic IP Jalousie-Aktors per "LED-Taster" integriert. Für mich zu spät.
Wenn das Backup-Verfahren bei mir funktionieren würde, wäre ich sehr glücklich. Anscheinend habe ich Pech damit, allerdings bin ich nach Lesen vieler Postings und Infos im Web nicht der einzige. Sogar in der aktuellen c't 24/2017 im Editorial (Seite 3: "Nebenwirkungen") wird kurz darauf angespielt.
Da bei mir der rfKey mit dem Sicherheitsschlüssel + "MD5" übereinstimmt, liegt der Verdacht also am "defekten" Backup-System der CCU1.
Falls es also einen Weg gibt, das Backup-System zu umgehen und direkt von einer CCU auf eine andere CCU per SSH/Telnet zu migrieren, stellt dies eine bessere Lösung dar, als ein stundenlanges Neu-Anlernen, bezeichnen, gruppieren, verknüpfen, skripten.
besten Dank für Deine Antwort.
Da ich schon alle Daten ab "/" per FTP von der CCU1 auf meine Festplatte geladen habe, wäre dies also kein Problem /usr/local/* per SFTP auf die RaspberryMatic zu kopieren und neu zu starten. Allerdings habe ich mich bis jetzt davor gescheut, dies zu tun, ohne ausreichende Hintergrundinformationen einzuholen.anli hat geschrieben:ich würde den Ordner /usr/local bei fertig geschriebener homematic.regadom aus der CCU1 nehmen und auf die CCU2 "spielen", zum Beispiel per SSH..
Meine Frage @all:
Hat dies schon jemand durchgeführt und musste danach noch nachkorrigiert werden? Gibt es Nebeneffekte mit "Gesichert"en BisCos-Geräten?
Dieses Problem hatte ich wirklich schon mal, deshalb musste ich die CCU1 neu aufsetzen inkl. alle Geräte in den Werkszustand versetzen. Der aktuelle Schlüssel hat nur Buchstaben und Zahlen, trotzdem klappt das Zurückspielen des Backups weder mit der CCU1 noch mit der RaspberryMatic.anli hat geschrieben:Hast Du Sonderzeichen im Sicherheitsschlüssel? Manche Versionen zickten damit rum, besonders mit & und ! kam es zu Problemen, dann war der Key nur der Teil bis zum Sonderzeichen. Würde allerdings nicht erklären, warum die MD5 übereinstimmen.
@all: Danke für Eure Kommentare.
Den Weg von ca. 50 BidCos-Geräten neu anzulernen hatte ich vor ca. zwei Jahren. Ein Cleaning hatte ich also schon .
Bei der Konzeption vor einigen Jahren war mir noch nicht bewusst, dass ein Anlernen eines HM-Gerätes nicht eine einmalige Sache ist. Beispielsweise sind meine HM-LC-Bl1-FM Jalousie-Aktoren ohne (!) Bedienungsschalter für Auf/Ab fest eingebaut. Für ein Neuanlernen muss ich also alle Aktoren temporär mit Schalter per 230V verdrahten. Anscheinend hat eQ3 dazugelernt und das Starten des Anlernmodus des Homematic IP Jalousie-Aktors per "LED-Taster" integriert. Für mich zu spät.
Wenn das Backup-Verfahren bei mir funktionieren würde, wäre ich sehr glücklich. Anscheinend habe ich Pech damit, allerdings bin ich nach Lesen vieler Postings und Infos im Web nicht der einzige. Sogar in der aktuellen c't 24/2017 im Editorial (Seite 3: "Nebenwirkungen") wird kurz darauf angespielt.
Da bei mir der rfKey mit dem Sicherheitsschlüssel + "MD5" übereinstimmt, liegt der Verdacht also am "defekten" Backup-System der CCU1.
Falls es also einen Weg gibt, das Backup-System zu umgehen und direkt von einer CCU auf eine andere CCU per SSH/Telnet zu migrieren, stellt dies eine bessere Lösung dar, als ein stundenlanges Neu-Anlernen, bezeichnen, gruppieren, verknüpfen, skripten.
Re: Vorgehensweise bei der Migration CCU1 -> CCU2 OHNE Backup
Hallo Smartdeveloper,
hattest Du erfolg?
Ich weiss ist schon ein bisschen her, aber kein anderer scheint so mutig zu sein
Viele Gruesse
Thomas
hattest Du erfolg?
Ich weiss ist schon ein bisschen her, aber kein anderer scheint so mutig zu sein
Viele Gruesse
Thomas