Devices von einer fhem auf einer anderen fhem übertragen

[wendeling]

Hallo,
ich möchte von einer vorhandenen fhem Installation alle devotes eines Raumes auf eine andere fhem Installation übertragen. Möchte da aber nicht jedes einzeln über raw kopieren !

Kann mir dabei jemand helfen ?

Gruß
Wendelin

[alanblack]

Ich sage mal "Jehova"
Du kannst ja die cfg nach den entsprechenden devices suchen.

Scherz beiseite! Selbst wenn du dir die Mühe gemacht hättest, die Räume jeweils in einzelnen Dateien gespeichert zu haben, bleibt immer noch das Umziehen von einem IOdev zum anderen.

Ich glaube, dass der sauberste Weg das Löschen auf dem einen und das neue Anlegen auf dem anderen FHEM ist.

[binford6000]

Ich glaube, dass der sauberste Weg das Löschen auf dem einen und das neue Anlegen auf dem anderen FHEM ist.

Korrekt. Hatte das auch vor ein paar Wochen gemacht. Alle Geräte mit IODevice hab ich letztlich dann doch neu angelegt.
Alle devices ohne IODevice kannst du bedenkenlos per RAW Kopie umziehen.
VG Sebastian

[Beta-User]

Wenn du mehrere RAW-Definitionen (z.B. wie hier raumweise) haben willst: list hat einen entsprechenden optionalen Parameter .

Dann nur ggf. in der DEF jeweils das IO umstellen => that's it...

(Frage mich nur, wofür man so eine Aktion braucht).

[alanblack]

Dann nur ggf. in der DEF jeweils das IO umstellen => that's it...

Naja, ein FS20- oder ein HM-Device oder... möchte wahrscheinlich dann doch eher unpaired und neu-gepaired werden. Ggf. mit anderem AES-Key oder ähnlichem...

(Frage mich nur, wofür man so eine Aktion braucht).

Ich hatte mich das auch kurz gefragt. Aber es scheint laut Sigs einige hier zu geben, die mehrere FHEMse parallel laufen lassen. Mir ist es bisher lieber, dass nur eine "Zentrale" läuft. Dazu noch ein Hardware-Duplikat in der Schublade, ein funktionierendes Backup... Sorry, ich schweife ab.

[wendeling]

Ok, Danke für die Antworten .

Werde dann doch es einzeln kopieren bzw. Neu anlegen.

Gruß
Wendelin

[Beta-User]

Werde dann doch es einzeln kopieren bzw. Neu anlegen.

Was machst du dann mit eventueller zugehöriger Logik?
Es macht m.E. mehr Sinn, Dinge, zu zusammen gehören auch zusammen umzuziehen (wenn es denn schon erforderlich/erwünscht ist)

Naja, ein FS20- oder ein HM-Device oder... möchte wahrscheinlich dann doch eher unpaired und neu-gepaired werden. Ggf. mit anderem AES-Key oder ähnlichem...

M.E. sind das zwei Paar Schuhe. Das FHEM-Device "kennt" zunächst mal (abgesehen von den Einstellungen am Device) z.B. bei HM die ganzen Details im Hintergrund gar nicht. Es läßt sich dann ggf. "nur" nicht steuern, bis auch die entsprechenden Einstellungen am Gerät selbst zum neuen IO passen. Und Geräte, die gar keine Sicherheitsfunktionen haben (wie die meisten 433-MHz-Gerätschaften) funktionieren ootb, für FS20 würde ich mal tippen, dass es genauso ist.

Aber klar ist: man muß in dem Zusammenhang alles auf irgendwelche Spezialitäten ansehen...

[Superposchi]

Ich hänge mich hier mal dran, weil ich gezwungenermaßen das gleiche Problem habe.
Musste einen komplett neuen Server aufsetzen, da in dem alten Fehler bei der Installation aufgetreten waren.

Jetzt muss ich alle Devices überführen, unabhängig vom Raum.
Gibt es da vielleicht eine Möglichkeit zu?

Gerade die Bridge für Homematic und Phillips Hue sind fest eingebaut und schwer zugänglich. Wenn es sich vermeiden lässt diese mühsam zum pairen zu bedienen wäre ich sehr erfreut.

[Beta-User]

Bis du sicher, dass du "dasselbe Problem" hast?

In der Regel reicht es, nach dem Einrichten des Servers ein Backup vom alten FHEM einzuspielen und dann ggf. wieder ein update zu machen. Dazu checken, ob alle erforderlichen Perl-Module da sind (wenn was fehlt, steht es im log), und gut ist.

Ansonsten: Sowohl die CCU wie auch die Philips-Bridge sollten mehrere Verbindungen akzeptieren, so dass du ggf. sogar alt und neu parallel fahren kannst, ein neues Pairing (Homematic) oder Einbinden in das ZigBee-Mesh sind in jedem Fall nicht erforderlich.

Bitte bei Bedarf einen eigenen Thread aufmachen und LIST (!) liefern, damit wir wissen, über was wir eigentlich sprechen, siehe den untersten der hier angepinnten Threads.

[MadMax-FHEM]

Bei Homematic: wie angebunden?

CUL_HM oder HMCCU

Bzgl. HUE-Bridge: Original oder deCONZ?


Wenn du ein fhem Backup machst und dann auf dem neuen System wieder einspielst, dann sollten die erwähnten Dinge wieder tun.
Hat zumindest bei mir problemlos schon mehrfach funktioniert.

ABER: ich habe deCONZ und CUL_HM

Allerdings solltest du deine Threads (schon wegen eigener Übersicht) nicht inflationär werden lassen

Und auch nicht immer wieder "kapern"

Gerade wenn, wei bei dir, die "Spezialität" Docker hinzukommt.

Gibt es bei Docker nicht die Möglichkeit auch Dateien vom Host einzubinden?
Manche legen doch z.B. das fhem-Verzeichnis etc. auf den Host und binden dann nur ein.
Damit wäre ein "Umzug" auf einen neuen/parallelen Container doch simpel?

Evtl. solltest du dich noch ein wenig mit deinem Docker beschäftigen...
...bevor du (noch mal) ein (nächstes) System aufsetzt...

Und: (weil du im Chromecast-Thread die selbe Frage gestellt hast) bzgl. Chromecast (aber auch generell) musst du halt die Pakete die notwendig sind installieren. Die Chromecasts kommen doch dann "von alleine" wieder, wenn du mal das "Python-Binding" Device hast...

Bzgl. deCONZ/HUE-Bridge bin ich mir nicht sicher, ob ein "Umzug" nur per "Raw-Definition" (wie hier vorgeschlagen soweit ich das überflogen habe) funktioniert, weil ja der Verbindungs-Code hinterlegt sein muss. Ich bin nicht sicher, ob das "crypt" was evtl. in der Raw-Def steht reicht...

EDIT: und auch noch mal wie Beta-User auch rät -> eigener Thread mit allen relevanten Infos! Statt: ich habe dasselbe Problem (was definitiv [Docker, soweit ich das im Kopf habe] nicht der Fall ist)...

Gruß, Joachim

[Superposchi]

Also für mich ist es das gleiche Problem. einzig der Punkt, dass es nicht auf einen Raum beschränkt ist unterscheidet sich.
Da in dem neuen Fhem bereits neue Devices existieren (für diese war ja das Neuaufsetzen notwendig), fällt meinem Verständnis nach ein Backup einspielen aus, da dann ja diese Devices wieder verschwunden wären, oder etwa nicht?
Zum Thema list, wovon soll ich bitte bei so einer allgemeinen Frage ein List hier reinstellen. Es geht nicht um ein spezielles Device, sondern um das große Ganze. soll ich dutzende einzelne List hier reinkopieren? Wie sinnvoll ist das, mal ehrlich?

Die Homematic-Bridge ist per Cul_HM eingebunden, es handelt sich dabei aber nicht um eine CCU, sondern lediglich um ein LAN-Gateway.
Die Phillips Hue ist Original

Was nennst du inflationär? Das ich nach ähnlichen Threats suche und mich daran hänge? Das ist eigentlich ein normales Vorgehen und in der Regel sogar gewünscht um die Anzahl an identischen Threats so gering wie möglich zu halten. Und speziell hier, wo man direkt gedisst wird wenn man keine Eigeniniziative zeigt ist es sinnvoll sich vorher zu informieren, oder nicht? Sorry wenn ich das sage, aber aus meinem Blickwinkel seid ihr hier im Forum die Sonderlinge, die sich anders als in den meisten anderen Foren verhalten. Beispielsweise das nicht nennen des Gesprächsspartners. Normalerweise Gang und Gäbe und erleichtert die Kommunikation immens, speziell wenn mehrere Leute gleichzeitig "kommunizieren". Für mich ist das fremdartig und ich komme damit ehrlich gesagt nicht wirklich klar. Jahrelange Gewohnheiten legt man eben nicht einfach so über Nacht ab.

Mit dem Docker hast du sicherlich recht, doch bei der Frage hier sollte das "Trägermedium" doch eigentlich keine Rolle spielen.
Das mit dem Einbinden ist korrekt, hätte aber meines Erachtens die gleiche Konsequenz wie ein Backup einzuspielen, oder nicht? Alles existierende wäre weg.

Ich müsste mich mit vielen Beschäftigen, das stimmt. Doch das Beschäftigen alleine reicht nicht. Man muss es auch verstehen. Und die Dokumentation zu Docker ist genauso zerklüftet wie die zu Fhem wenn man nicht weiß wo und wonach man suchen muss.

Und: (weil du im Chromecast-Thread die selbe Frage gestellt hast) bzgl. Chromecast (aber auch generell) musst du halt die Pakete die notwendig sind installieren. Die Chromecasts kommen doch dann "von alleine" wieder, wenn du mal das "Python-Binding" Device hast...

Es ist ja nicht nur Chromecast, sondern auch FhemConnect mit dem Gassistant. Es fehlten grundlegende Parameter bei der Containererstellung, so dass etliche Befehle nicht ausgeführt werden konnten auf dem alten Container. Diese habe ich mit der Hilfe einiger hilfsbereiter Forumsmitglieder beim Neuaufsetzen (das nachträgliche implementieren ging eben nicht) gelöst. Es in den bestehenden Container zu implementieren wäre mir sicherlich lieber gewesen. Denn mir war dieses jetzige Problem des Umzugs schon schnell klar war.
Und das die Frage zuerst in Chromecast gestellt wurde hängt einfach damit zusammen, dass es ein Resultat der Aktionen aus diesem Threat sind. Wenn dann dort keine Antwort mehr erfolgt - weil das Thema nicht wirklich zum Threattitel passt - ist es eigentlich normal sich einen passenderen Threat zu suchen und dort nachzufragen. Hier soll aber anscheinend lieber der 38ste Threat mit gleichem Inhalt aufgemacht werden statt einen alten Fortzusetzen.

eigener Thread mit allen relevanten Infos! Statt: ich habe dasselbe Problem (was definitiv [Docker, soweit ich das im Kopf habe] nicht der Fall ist)

Ja richtig, ich nutze Docker statt einem Raspi, doch was hat das mit dem Problem zu tun? Fhem ist doch ein unabhängiges System und ich kopiere die Devices ja nicht physisch sondern von einem Fhem zum anderen Fhem und genau dieses Problem hat der Threatersteller auch nachgefragt. Also ja, für mich ist es das gleiche Problem.

Und bitte nehmt mir beide meine Ausführungen nicht krumm, es soll lediglich eine Erklärung sein, kein Angriff oder Wiederspruch. Jedes Forum hat gewisse Eigenheiten, aber in diesem sind diese Eigenheiten so gravierend, dass es für mich wie eine eigene Welt wirkt.

[Beta-User]

MACH EINEN EIGENEN POST AUF!

Du kaperst einen fremden Thread, egal, ob es "für dich" dasselbe Problem ist oder nicht. Diese Leiche war seit über zwei Jahren tot, also behellige nicht andere mit aktuellen Problemen, die VIELLEICHT wirklich dieselben sind.

Ich bin jedenfalls hier raus und werde auch nichts mehr schreiben, wenn du dich nicht an die _allgemein gültigen_ Regeln hälst und diese ständig durch deine eigenen ersetzen willst.

[MadMax-FHEM]

Also damit hast du selbst belegt, dass dein Problem durchaus (deutlich) anders ist.

Und wie es mittels Raw-Definition geht steht hier und auch anderswo...

Und nun kommen eben die Anmerkungen bzgl. Hue (siehe meine Antwort)...

Und wenn eben für das zu übertragende Device Perl-Module auf OS-Seite fehlen, dann kommt sehr wohl Docker ins Spiel...

Das nur "quick&dirty" weil ich grad nur am Handy zugange bin...

Eins noch: klar, wenn du per CUL_HM eingebunden hast, hast du natürlich keine CCU (weil das wäre dann HMCCU   )...

Und bzgl. des HMLAN einfach das IO-Modul im "alten" fhem deaktivieren und übertragen per Raw-DEF.
Und da wären wir schon wieder bei einer Abweichung zum Thread: bei der Übertragung von CUL_HM-Devices gibt es einiges zu beachten.
Daher wäre dafür ein gesonderter Thread im Homematic Unterforum sinnvoll.
Bzw. dort mal schauen, gibt schon einige Threads...

Gruß, Joachim

[Superposchi]

wenn du dich nicht an die _allgemein gültigen_ Regeln hälst und diese ständig durch deine eigenen ersetzen willst

Allgemein gültig ist das, was in der Mehrzahl vergleichbarer Optionen praktiziert wird. Die hiesigen untypischen Verhaltensregeln sind eben nicht das allgemein gültige, sondern der Sonderfall. Das ist es was ich dir seit mehreren Posts versuche zu erklären

Aber wer bin ich denn, dass ich mich mit Gott streiten würde.



Wenn wir gerade beim CUL_HM-Device sind:
Wahrscheinlich ist es etwas anders zu handhaben als ein Hue-Device, aber die grundlegende Frage ob es eine Möglichkeit gibt einfach alle Devices aus einem Fhem-System auf ein anderes Fhem-System zu übertragen ist doch davon nicht betroffen. Das ein Device nicht wie das andere ist gilt für jedes einzelne - ergo müsste man für jedes Device einen eigenen Threat aufmachen. Die Logik dahinter erschließt sich mir nicht Du denkst meines Erachtens viel zu spezifisch. Die Frage ist, ob es einfach einen Befehl ala "Copy" gibt, der das komplette Device oder sogar eine Gruppe von Devices 1:1 in ein anderes System kopiert. Was ist daran anders als bei der Fragestellung des Threaterstellers. Ehrlich, ich möchte es wirklich verstehen, doch das ist mir zu hoch. Abgesehen davon, dass ich weder mit dem Begriff OS-Seite was anfangen kann, noch den Unterschied zwischen einem Device und einem IODevice kenne. Abkürzungen sind ohne Erläuterung des Menschen geistiger Tod. Dazu kommt auch, dass ich nicht weiß was da fehlen soll.

Als Analogie: Ich habe zwei Töpfe mit Wasser und diversen Eiern drin. Nun will ich die Eier aus Topf A in Topf B kopieren/verschieben. Ja, jedes Ei ist etwas anders in Größe und Form, dennoch ist der Vorgang grundlegend der gleiche. Es spielt doch weder eine Rolle wie groß der Topf ist, noch wie heiß das Wasser etc.
Im spezifischen bedeutet das, ich habe ein System A und ein System B und meine Devices entsprechen den Eiern. Wieso spielt es eine Rolle das System A andere Routinen/Parameter hat als System B?

Ich habe den Eindruck entweder du denkst zu komplex oder ich nicht komplex genug, aber offenbar gibt es eine Möglichkeit das gleiche zu sagen und dennoch aneinander vorbei zu reden.

[Beta-User]

Was ist an: "Mach einen neuen Thread auf" missverständlich?

Ich habe kein Problem damit, zu versuchen, alles mögliche zu erläutern, aber hier riecht es nach Leichenfledderei. Und Leichenfledderei wird hier in diesem Forum nicht so gern gesehen, weswegen du auch beim Erstellen deiner Antwort direkt einen Warnhinweis erhalten hast. Das ist doch _allgemein gültig_, oder gibt es bei dir andere Einstellungen?