piVCCU mit CCU3 Firmware

[klassisch]

Herzlichen Dank für die Anleitung!

[uwe111]

das Verhalten beim Einspielen von Backups ist auf der CCU3 ein anderes als auf einer RM! Die CCU3 macht wirklich "Cherrypicking", und holt sich aus einem CCU2-Backup absolut nur gezielt die Dateien, die auch wirklich einen "EQ3-Ursprung" haben, und für die WebUI bzw. die Schnittstellen gebraucht werden.

Wie verhält es sich beim Einspielen eines CCU3-Backups auf einer CCU3? Wird da auch gefiltert oder bleiben die AddOns dann drin?

Viele Grüße

Uwe

[deimos]

Hi,

Wie verhält es sich beim Einspielen eines CCU3-Backups auf einer CCU3? Wird da auch gefiltert oder bleiben die AddOns dann drin?

So wie ich den Code verstanden habe, wird in dem Fall das komplette Backup eingespielt, nur beim Wechsel von CCU2 nach CCU3 wird das Cherrypicking betrieben. Beim Wechsel von CCU1 zu CCU3 wird das dann noch komplizierter, da werden teilweise sogar noch Anpassungen an den Configs vorgenommen.

Viele Grüße
Alex

[jmaus]

das Verhalten beim Einspielen von Backups ist auf der CCU3 ein anderes als auf einer RM! Die CCU3 macht wirklich "Cherrypicking", und holt sich aus einem CCU2-Backup absolut nur gezielt die Dateien, die auch wirklich einen "EQ3-Ursprung" haben, und für die WebUI bzw. die Schnittstellen gebraucht werden.

Wie verhält es sich beim Einspielen eines CCU3-Backups auf einer CCU3? Wird da auch gefiltert oder bleiben die AddOns dann drin?

Die Addons und alles andere bleibt drin. Lediglich beim Einspielen eines CCU2 (Firmware 2.x.x) Backups in eine CCU3 kommt es zu besagten Filterung und auslassen der Daten von Addons. Jedoch sei auch noch erwähnt das sich hier die nächste auf 3.37.8 basierende RaspberryMatic etwas anders verhalten wird. Dort wird es möglich sein problemlos sein aus RaspberryMatic 2.x.x kommendes Backup in RaspberryMatic 3.x.x einzuspielen ohne das die Filterung passieren wird. Lediglich wenn man von einem CCU2 Backup kommt wird sich dann RaspberryMatic 3.x.x gleich wie eine CCU3 verhalten und die Backupdaten entsprechend filtern.

[deimos]

Hi,

das Verhalten beim Einspielen von Backups ist auf der CCU3 ein anderes als auf einer RM! Die CCU3 macht wirklich "Cherrypicking", und holt sich aus einem CCU2-Backup absolut nur gezielt die Dateien, die auch wirklich einen "EQ3-Ursprung" haben, und für die WebUI bzw. die Schnittstellen gebraucht werden.

Wie verhält es sich beim Einspielen eines CCU3-Backups auf einer CCU3? Wird da auch gefiltert oder bleiben die AddOns dann drin?

Die Addons und alles andere bleibt drin. Lediglich beim Einspielen eines CCU2 (Firmware 2.x.x) Backups in eine CCU3 kommt es zu besagten Filterung und auslassen der Daten von Addons. Jedoch sei auch noch erwähnt das sich hier die nächste auf 3.37.8 basierende RaspberryMatic etwas anders verhalten wird. Dort wird es möglich sein problemlos sein aus RaspberryMatic 2.x.x kommendes Backup in RaspberryMatic 3.x.x einzuspielen ohne das die Filterung passieren wird. Lediglich wenn man von einem CCU2 Backup kommt wird sich dann RaspberryMatic 3.x.x gleich wie eine CCU3 verhalten und die Backupdaten entsprechend filtern.

Und was genau hat das jetzt mit piVCCU zu tun?

Viele Grüße
Alex

[jmaus]

das Verhalten beim Einspielen von Backups ist auf der CCU3 ein anderes als auf einer RM! Die CCU3 macht wirklich "Cherrypicking", und holt sich aus einem CCU2-Backup absolut nur gezielt die Dateien, die auch wirklich einen "EQ3-Ursprung" haben, und für die WebUI bzw. die Schnittstellen gebraucht werden.

Wie verhält es sich beim Einspielen eines CCU3-Backups auf einer CCU3? Wird da auch gefiltert oder bleiben die AddOns dann drin?

Die Addons und alles andere bleibt drin. Lediglich beim Einspielen eines CCU2 (Firmware 2.x.x) Backups in eine CCU3 kommt es zu besagten Filterung und auslassen der Daten von Addons. Jedoch sei auch noch erwähnt das sich hier die nächste auf 3.37.8 basierende RaspberryMatic etwas anders verhalten wird. Dort wird es möglich sein problemlos sein aus RaspberryMatic 2.x.x kommendes Backup in RaspberryMatic 3.x.x einzuspielen ohne das die Filterung passieren wird. Lediglich wenn man von einem CCU2 Backup kommt wird sich dann RaspberryMatic 3.x.x gleich wie eine CCU3 verhalten und die Backupdaten entsprechend filtern.

Und was genau hat das jetzt mit piVCCU zu tun?

Nicht viel. Aber in der Konversation wurde explizit auch auf RaspberryMatic eingegangen, deshalb meine Erläuterung/Klarstellung dazu.

[rbeudel]

Hallo,
ich war mutig und habe piVCCU3 auf meinem System installiert. Ein Schreck gab es, eine Fehlermeldung das kein Modul erkannt wurde. Nächster Schreck, die alte Oberfläche tauchte wieder auf, war aber der Browser, die PiVCCU war auf einer neuen IP. PiVCCU noch mal gestartet dann keine Fehlermeldung, Backup eingespielt und es scheint zu Funktionieren. Natürlich alle Zusatzprogramme weg. Werde ich nach und nach wieder installieren.
Openhab hat auch Zugriff.
Viele Grüße,
Ralf

[klassisch]

Hi,
piVCCU hat einen Dummy-Mode für das Funkmodul, den ich noch nie benutzt habe und deshalb nicht kenne.
Hat piVCCU auch sowas? Und könnte ich damit:
- Meinen Ersatz-OPi mit piVCCU3 bespielen
- Dummy-Funkmodul auswählen
- In aller Ruhe und gefahrlos alle Addons installieren und sichten, und teilweise auch testen
- Wenn alles zu funktionieren scheint, die Opis runterfahren
- Opis im Gehäuse tauschen
- Nach der Fritten-Karenzzeit die IPs neu verblocken
- piVCCU3 neu starten
- Funkmodul auf das richtige ("altes", billigeres, LED-blinkfreies) Funkmodul umstellen
- ggf neu starten
- piVCCU2 haben
Wäre das ein sanfter Migrationspfad mit einem Minimum an Unterbruch?

[deimos]

Hi,

rein auf Homematic betrachtet kannst du das so machen. Wenn da noch CUxD, Hue oder ähnliches dazu kommt, musst du halt schauen, dass die nicht doppelt "senden".

Nach dem Umstellen zwischen Funkodul und Software Emulation musst du aber jeweils neu starten (egal in welche Richtung der Wechsel geht)

Viele Grüße
Alex

[klassisch]

Vielen Dank!

"Neu Starten" mein piVCCU neu starten oder host neu starten? Ich würde jetzt piVCCU stoppen und host neu starten.
Den CUL-Stick würde ich erst verbinden, wenn CUxD funktionsfähig scheint und nach dem Umbau ins Gehäuse.
CUxD sendet bei mir eher wenig, ich brauche ihn vor allem für den Empfang und das Einbinden der WeMos-Sensoren. Da wird nichts böses passieren, weil ich mit piVCCU ja keine Daten speichere, sondern mit ioBroker und die Verbindung wird erst aufgebaut wenn alles klappt und die IPs getauscht sind.
So, Reserve OPI ist an Deck, möchte aber noch 15 updates....