[FHEM System] Umzug / Splittung von FHEM auf 2 Systeme

[Kermit20]

Hallo Gemeinde,

nach langer "Abstinenz" habe ich vor mein FHEM System zu entstauben und auf Vordermann zu bringen.

Infos: aktuell läuft FHEM mit allem drum und dran auf einem RaspberryPi 3. Ziel ist es "Produktion" und "Test" zu trennen. Das neue System (IntelNUC mit Mint/Docker) läuft soweit und ist mit einer neuen Struktur eingerichtet (FHEM neue Hauptinstanz im Container sowie weitere für SONOS, LAB usw.). Dies stellt mich aktuell vor die Herausforderung die weiterführende Migration zu planen. Ich habe schon im Forum und im Netz gesucht... leider findet man in der Regel nur Informationen zur Migration des gesamten Systems über den weg des Backups und dieses wieder einzuspielen. Mein Ziel ist aber ja, wie beschrieben, nur Teile der Konfiguration zu übernehmen... z.B. die VCCU mit den I/Os und den dazugehörigen Homematic Geräten (Eine neue Einrichtung der VCCU mit den I/Os wäre sicher am saubersten... leider komme ich nicht an alle Aktoren um diese neu zu pairen).

Nun zu meiner Frage an euch, wie wären aus eurer Sicht die günstigsten Maßnahme um das System auf die neue Plattform zu migrieren ? evtl. Filetierung der alten CFG in die relevanten Schnipsel und der Weg über den RAW Import ?

Danke im Voraus für alle Vorschläge 

Gruß

[Beta-User]

evtl. Filetierung der alten CFG in die relevanten Schnipsel und der Weg über den RAW Import ?

Genau so...

(Du brauchst insbesondere den HM-Teil nicht neu zu pairen, wenn du die bisherige HmID der VCCU beibehältst). Bitte aber möglichst darauf achten, dass du immer die "richtige Reihenfolge" einhältst, also erst das/die IO, dann ggf. die logische Zwischenschicht für die IO's (hier: VCCU), dann die (Hrdware-) Devices (CUL_HM), zum Schluss dann wieder erst logische Zwischenschichten wie structure usw., am Ende dann andere Eventhandler wie notify, THRESHOLD und DOIF, Lightscene....

Viel Erfolg,

Beta-User

[Otto123]

Hi,

z.B. die VCCU mit den I/Os und den dazugehörigen Homematic Geräten (Eine neue Einrichtung der VCCU mit den I/Os wäre sicher am saubersten... leider komme ich nicht an alle Aktoren um diese neu zu pairen).

bezüglich HM ist die Übernahme auf Grund der Entwicklung des letzten Jahres leider nicht mehr ganz trivial.
Aber versuch mal folgendes:
IO definieren (ich hoffe Du hst was ordentliches und keinen CUL)
VCCU definieren (wie schon gesagt: gleiche HMId wie im alten System)
einen Aktor mit der Seriennummer (altes System) mit der VCCU mit hmPairSerial pairen. (2x mit Ruhe und Abstand)
Das sollte das Gerät einfach neu anlegen, nach neuem Schema Ohne ALtlast.
Wenn das klappt wäre es auch ein Weg.

Du kannst auch aus dem alten System mit Filtern exportieren und im neuen System importieren. Wenn Du willst sag ich Dir wie, ansonsten nimmst Du stückweise manuell die Raw Definition.

Gruß Otto

[msome]

Hallo Otto,

bezüglich HM ist die Übernahme auf Grund der Entwicklung des letzten Jahres leider nicht mehr ganz trivial.

könntest du bitte einen Hinweis geben, wo hier die großen Änderungen liegen?
Stichworte würden mir schon reichen, die Details finde ich dann schon raus.

Der Grund ist, ich fahre mit meinem Haupt-FHEM schon seit Ende 2016 keine Updates mehr. "Never touch a running system".
Eine Handvoll FHEM Module habe ich mal manuell hochgezogen oder ge-merged, wenn Funktionen hauptsächlich mit Daten ausm Netz nicht mehr funktioniert hatten.
Jetzt würde ich aber auf ein neues Odroid Modell als Basis wechseln und da hat sich mir auch die Frage gestellt - einfach die alte Config wieder einspielen und hoffen, oder neu aufsetzen.
Eigentlich hätte ich nur die Config-Datei kopiert und wieder lauffähig gemacht - aber dein Post hat mich verunsichert.

Ich habe aktuell 54 Geräte mit 162 Kanälen nur auf Homematic "classic" im Betrieb (das "alte" BidCoS System).

Danke, Matthias

[Otto123]

Hallo,

ich bin kein Freund davon die fhem.cfg manuell zu erstellen und zu bearbeiten. FHEM liefert ja gute Möglichkeiten und Schnittstellen.

Normalerweise kann man Geräte / Gruppen per Raw Definition schön übernehmen. Ich habe mir einen Client für de Web Schnittstelle gebaut, da kann ich mit devspec filtern und ziemlich locker Teile der config von Server A nach B spielen.

Einzig mit Homematic geht das leider nicht mehr so easy:
https://forum.fhem.de/index.php/topic,103344.msg970208.html#msg970208

Einfach config kopieren und FHEM neu starten geht.

Zu einem 3 Jahre altem System darfst Du hier aber dann auch keine Problemlösungen mehr erwarten. Da hat sich so viel geändert, dass weiß heut gar keiner mehr

Gruß Otto

[LuckyDay]

Der Hm Teil mit RAW Import von alten DEF's aus 2016 , wirst du auf die Nase fallen.
Aber , HM konvertiert die alten DEF'S  wenn Fhem aus der fhem.cfg direkt liest bei fhemstart.

erst die HM/IO's
dann VCCU
dann Hauptdevice
dann die zugehörigen Kanäle des Device
dann das nächste Hauptdevice
dann die zugehörigen Kanäle des Device
usw.

[msome]

Zu einem 3 Jahre altem System darfst Du hier aber dann auch keine Problemlösungen mehr erwarten. Da hat sich so viel geändert, dass weiß heut gar keiner mehr

Vielen Dank, sowas habe ich gesucht. Ich hab's dank dem Link die Problematik mit .mId und modelForce verstanden.
Und keine Angst, ich brauch keinen Support beim Umstieg selbst nur wegen alter Definitionen, dafür bin ich schon zu lange bei FHEM dabei. Wenn ich Hilfe brauche dann bei Perl. Mit dieser Sprache kann ich mich als ANSI-C-Hase nicht anfreunden.

Das Topic rund um die Probleme bei der Einführung von mId war auch ganz aufschlussreich wie das Konzept dahinter sein sollte - und jetzt ist.

Aber , HM konvertiert die alten DEF'S  wenn Fhem aus der fhem.cfg direkt liest bei fhemstart.

Hi, vielen Dank. Das war der Hinweis wie ich die Migration hinbekommen kann.
Hab gerade mal meine alte FHEM Version auf den PC kopiert und damit eine Test-FHEM-Instanz gestartet.
Natürlich mit einer Minimal-Konfig mit nur 5 HM Geräten aus der alten Config im fhem.cfg file. Dann habe ich erst ein update, dann noch ein update force gemacht und mal die 10_cul_hm.pm und fhem.pl kontrolliert - beide sind jetzt vom August 2019.
Nach mehreren shutdown restart, 5s warten (hab ich im cul_hm code gefunden) und save stehen zwar immer noch die alten "model" Attribute im fhem.cfg - aber auch die neuen  .mId (und setuuid).

Damit habe ich jetzt durch die automatische Migration ein "neues" fhem.cfg auf Basis der alten Datei das ich dann direkt der neuen Installation unterschieben können sollte.

Vielen Dank für die Hinweise. 

[Otto123]

Moin,

am model Attribute hat sich ja nichts groß was geändert. Bei manchen Modellen wurde m.W. die Schreibweise vereinheitlicht.

Wenn Du am probieren bist, kannst Du Dir ja wie schon gesagt mit einem wiederholten pairen mit hmPairSerial eine nagelneue config machen lassen. Dabei passiert nichts in deinem Aktor, er ist ja schon gepairt. Er wird aber veranlasst seine Anlernnachricht (und die Informationen darin) zu schicken. Das kannst Du alternativ dadurch erreichen in dem Du das Gerät in den Anlernmodus versetzt und nach Anlage des Gerätes (passiert durch autocreate) noch ein getConfig nachschieben. Das getConfig wird beantwortet, da das Gerät ja gepairt ist. Damit ist die config für dieses Gerät komplett und neu.
Also nur für den Fall, dass Dich interessiert wie gut oder schlecht das Update der alten config ist

Gruß Otto

[Verkehrsrot]

Ich habe ein ähnliches Umzugsthema, nicht ganz so komplex, aber frage mich wie ich am besten vorgehe. Kann mir jemand Tips geben?

Ich habe ein jahrelang betriebenes RPi Fhem, das ich nun auf einen frischen RPi mit aktuellem Betriebssystem umziehen will. Habe mir den neuen RPi mit frischem "nackten" Fhem hochgezogen und bereitgelegt. Nun will ich das alte System dort drauf haben. Das alte Fhem habe ich zur Vorbereitung einigermaßen aufgeräumt. Hminfo configcheck läuft fehlerfrei durch, und fhem version ist aktuell.

Die Gateway-Hardware (Zwave, Jeelink, RFXTRX, Bluetooth) will ich 1:1 übernehmen, außer das HMLAN Gateway. Dieses will ich durch eine RPI-MOD-PCB Platine im neuen RPi ersetzen.

Nun stellen sich mir zwei Fragen:

1) Wie gehe ich vor zum Tausch des HM Gateways? Gern vermeiden möchte ich ein neues Pairing aller Devices, denn dazu müsste ich viel herumlaufen und hantieren. Wie mache ich das am besten?

2) Im Dateibaum /opt/fhem des alten Systems liegen hunderte MB Betriebsdaten der letzte Jahre, z.B. riesige Logdateien, die ich nicht mit umziehen will. Wie gehe ich dazu am besten vor?
- Backup/Restore von Teilen des /opt/fhem Verzeichnisses? (welche sind wichtig?), oder
- Device für device händisch einzeln umziehen?

Danke für einen Praxistip, bevor ich herumirre und viel Zeit verbrate.

[Beta-User]

Einfach weiter die alte HmId für das Interface bzw. die VCCU nehmen .
Wenn das alte IO weg soll, kannst du auch einfach die DEF des alten IO ändern, dann bleibt es sogar an derselben Stelle in der Config...
Ansonsten kannst du die Logs (nach dem Restore) wegwerfen und den Rest lassen, das ist in der Regel das einfachste (Speicherplatz kostet ja praktisch nichts).

Im Detail bereinigen ist zwar wünschenswert, aber ob du dir das antun willst?

[Otto123]

Hi,

das alte System einfach backup und restore. Falls Du dazu Befehle brauchst - hier.

Das mit der DEF (Tipp von Beta-User) ist ne interessante Idee, aber geht die wirklich wenn man mit defmod den Namen beibehält? - muss ich mal probieren

Ansonsten nrarchive attribute zum selbstätigen Logfile Handling von FHEM benutzen ansonsten kannst Du alte Log Dateien einfach löschen. Das stört FHEM nicht.

Gruß Otto

[Beta-User]

Das mit der DEF (Tipp von Beta-User) ist ne interessante Idee, aber geht die wirklich wenn man mit defmod den Namen beibehält? - muss ich mal probieren

Just do it .
Solange der TYPE erhalten bleibt, ist das nach meiner bisherigen Erfahrung kein Problem .
(Dto. mit allen Geräten, die seriellen Verbindungen benötigen: ob man die jetzt an GPIO, USB-UART-Wandler oder via MapleCUN (oder ser2net &Co, aber da habe ich keine Erfahrung) betreibt, ist (bis auf das nicht ganz unwichtige Latenzen-Thema...) im Prinzip egal . Auch da kann man die DEF schlicht ändern, vom USB-CUL auf ATMega32U-Basis mit uralt-firmware auf Maple-STACKABLE-4, 1. Stack angebunden über LAN...).

[Verkehrsrot]

Einfach weiter die alte HmId für das Interface bzw. die VCCU nehmen .
Wenn das alte IO weg soll, kannst du auch einfach die DEF des alten IO ändern, dann bleibt es sogar an derselben Stelle in der Config...

d.h. ich mache es so:
1. Backup auf altem System machen, altes System runterfahren
Danach auf neuem System:
2. Frisches fhem nackt starten
3. Neues IO Device (RPI-MOD-PCB) mit define anlegen und auf gleiche HmId konfigurieren wie HMLAN im alten System
4. Resultierende fhem.cfg sichern
5. fhem stoppen
6. restore vom alten System
7. fhem.cfg des alten Systems manuell editieren und mit neuen Settings aufs Schritt 4 zusammenführen
8. fhem wieder starten

Richtig?
Pairings und Peerings brauchen dann nicht angefasst zu werden?


richtig?

[Otto123]

Solange der TYPE erhalten bleibt, ist das nach meiner bisherigen Erfahrung kein Problem .

Aber genau das ist der Punkt, es ist ja ein anderer TYPE ! Vorher HMLAN danach HMUARTLGW !
@ Verkehrsrot
Jein.
Beta-Users Idee ist anders.

Aber ansonsten ist der Gedanke gut weil: Der IO für HM sollte am Anfang in der Config stehen. Insofern kannst Du es aber anders machen.

Aber warum willst Du den HMLAN unbedingt vorher rauschmeißen? Lass ihn doch erstmal und probiere ob alles läuft. Bau dann das HMUARTLGW ins neue System ein.

Peerings stehen sowieso in den Geräten. Da liest FHEM nur mit.
Pairing bleibt wegen gleicher hmId erhalten, brauchst Du nicht anfassen.

Gruß Otto

[Beta-User]

Aber genau das ist der Punkt, es ist ja ein anderer TYPE ! Vorher HMLAN danach HMUARTLGW !

Thx, hatte das nicht vorher im Detail geprüft; dann geht das so nicht...

Aber ansonsten ist der Gedanke gut weil: Der IO für HM sollte am Anfang in der Config stehen. Insofern kannst Du es aber anders machen.

Sollte man zwischenzeitlich aber auch nicht mehr überbewerten...

Aber warum willst Du den HMLAN unbedingt vorher rauschmeißen? Lass ihn doch erstmal und probiere ob alles läuft. Bau dann das HMUARTLGW ins neue System ein.

UNBEDINGT!
Erst testen, ob alles auf demselben Level läuft, selbst wenn der "na ja" ist...

Dann hast du zwei Wege:
Entweder löschen + neues IO mit denselben HmID-Daten (und AES-keys, sofern genutzt) anlegen, ODER (und das ist der zu empfehlende Weg) du nutzt die Gelegenheit, und ziehst "endlich" eine VCCU ein. Hat nur einen Haken: Es gibt ggf. neue, zusätzliche Events (to VCCU), die mit deinen Eventhandlern kompatibel sein müssen (mit den Stichworten aus diesem Thread solltest du mehrere Threads mit mir und Otto finden, die das behandeln, meistens ist es eher ein theoretisches Problem ).
Im Detail: Du beginnst mit der alten Konfiguration, und erweiterst die um eine VCCU (wieder mit den vorhandenen Daten) und ordnest ihr dann beide IO's (oder mehr) unter.