Kopie von ioBroker auf einen Slave-RPI 4
-
Hallo Leute,
nachdem ich nun erfolgreich einen RPI 4 8GB mit ioBroker nutze, wollte ich nun meinen zweiten RPI 4 8GB in Verwendung nehmen und diesen als Slave nutzen.
Da ja alles schon auf den ursprünglich RPI konfiguriert ist dachte ich einfach einen kopie von allem zu machen und auf den neuen RPI zu übertragen und anschließend nurmehr den zweiten RPI im ioBroker als Slave zu konfigurieren und die dementsprechenden adapter dort aktivieren - oder denke ich da falsch? ich habe null Erfahrung mit Master/Slave....
Reicht es einfach den Inhalt der SSD des jetzigen RPI's zu auf den für den neuen RPI verwendeten USB-Stick zu kopieren? (glaub ich kaum dass das einfach so funkt...)Nachdem das mal läuft wollte ich PIVCCU3 installieren und dieses mit den HmIP-RFUSB nutzen - wo auch noch unklar ist wie ich das überhaupt mache (iobroker und HMIP auf ein System)
Wie auch bisher immer - danke euch schonmal für eure große Unterstützung!
LG
-
@igor123 ganz folgen kann ich dir noch nicht.
du hast
- einen laufenden Pi4-8GB?
- einen neuen Pi4-8GB, der zum Slave werden soll?
du willst
- einige jetzt auf dem zukünftigen Master laufenden Instanzen später auf dem Slave laufen lassen`
- auf dem zukünftigen Master (oder Slave???) zusätzlich piVCCU installeiren
-
@homoran sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@igor123 ganz folgen kann ich dir noch nicht.
du hast
- einen laufenden Pi48GB?
RICHTIG
- einen neuen Pi48GB, der zum Slave werden soll?
RICHTIG
du willst
- einige jetzt auf dem zukünftigen Master laufenden Instanzen später auf dem Slave laufen lassen`
RICHTIG
- auf dem zukünftigen Master (oder Slave???) zusätzlich piVCCU installeiren -
ich dachte am Slave - oder was eurer Meinung nach am Sinnvollsten ist?
MOD-Edit: Text korrekt formatiert
-
@igor123 sagte: zweiten RPI 4 8GB in Verwendung nehmen und diesen als Slave nutzen.
Weshalb ein Slave? An zu wenig RAM kann es wohl nicht liegen.
-
@igor123 sagte: iobroker und HMIP auf ein System
Mit piVCCU geht das.
-
@paul53 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@igor123 sagte: zweiten RPI 4 8GB in Verwendung nehmen und diesen als Slave nutzen.
Weshalb ein Slave? An zu wenig RAM kann es wohl nicht liegen.
Hast vollkommen recht - nur wird sich der neue PI4 mit nur PIVCCU drauf langweilen (denke ich mal?) - warum nicht gleich als Slave nutzen und somit "unendlich" RAM haben
-
@igor123 sagte: der neue PI4 mit nur PIVCCU drauf langweilen
Weshalb nicht piVCCU auf dem bestehen ioBroker-Pi 4?
-
@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
ich dachte am Slave - oder was eurer Meinung nach am Sinnvollsten ist?
fangen wir mal von hinten an
Ich hatte früher immer mal ein paar Testinstallationen von piVCCU/YAHM/lxccu und darauf dann ioBroker installiert und zum Slave gemacht
Ist also egal wie kein Problem. War nur für die mögliche Vorgehensweise von Belang.
Vorschlag für einfachstes Vorgehen:
- auf der Seite von Alex ein Image für piVCCU3 auf RasPi herunterladen
- iobroker mit dem Installer
* curl -sLf https://iobroker.net/install.sh | bash -installieren - alle Instanzen deinstallieren (ich habe beim letzten Test wirklich alles incl. admin deinstalliert)
- Multihost aufbauen
- Im Slave
iobroker setup customausführen und die IP des Masters als Speicherort eingeben
- Im Slave
- Erst Master, dann Slave rebooten
- jetzt müsste das Multihostsystem stehen
- über den admin des Masters die Instanzen auf den Slave verschieben
-
@paul53 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@igor123 sagte: der neue PI4 mit nur PIVCCU drauf langweilen
Weshalb nicht piVCCU auf dem bestehen ioBroker-Pi 4?
Da ich den Pi 4 zu Weihnachten erhalten habe und für etwas nutzen will.
-
@paul53 sagte:
Weshalb nicht piVCCU auf dem bestehen ioBroker-Pi 4?
Bei mir war es wegen der besseren Position
-
@igor123 sagte: Da ich den Pi 4 zu Weihnachten erhalten habe und für etwas nutzen will.
Das ist ein tolles Argument, um ein komplexeres System mit mehr Fehlermöglichkeiten aufzubauen.
-
@homoran sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
ich dachte am Slave - oder was eurer Meinung nach am Sinnvollsten ist?
- alle Instanzen deinstallieren (ich habe beim letzten Test wirklich alles incl. admin deinstalliert)
Vom Master, also vom derzeit laufenden System, alle Instanzen deinstallieren?
Falls ja kann ich das nicht ohne weiteres laufen bzw. wäre mir zu unsicher dass ich es, aus welchen Grund auch immer, nicht am selben Tag zum laufen bekomme und dann stehe ich beispielsweise ohne Licht da...
-
@paul53 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Das ist ein tolles Argument, um ein komplexeres System mit mehr Fehlermöglichkeiten aufzubauen.
Ich muss gerade schmunzeln. Ich hatte hier lange auch einen secondary host 'ohne Not, nur weil es geht' laufen. Hab ich die Tage auch wieder aufgelöst. Ist ja auch ein Widerspruch zum KISS-Prinzip.
-
@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Vom Master, also vom derzeit laufenden System, alle Instanzen deinstallieren?
nein!
auf dem neuen, der dann Slave werden soll
-
@thomas-braun sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@paul53 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Das ist ein tolles Argument, um ein komplexeres System mit mehr Fehlermöglichkeiten aufzubauen.
Ich muss gerade schmunzeln. Ich hatte hier lange auch einen secondary host 'ohne Not, nur weil es geht' laufen. Hab ich die Tage auch wieder aufgelöst. Ist ja auch ein Widerspruch zum KISS-Prinzip.
Dito!
nur weil es geht!
-
@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Vom Master, also vom derzeit laufenden System, alle Instanzen deinstallieren?
Nein, es sind die voreingestellten Adapter auf dem frischen ioBroker gemeint, bevor der zum 'Nebenhost' degradiert wird.
-
@paul53 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@igor123 sagte: Da ich den Pi 4 zu Weihnachten erhalten habe und für etwas nutzen will.
Das ist ein tolles Argument, um ein komplexeres System mit mehr Fehlermöglichkeiten aufzubauen.
Naja, aber mit den neuen Pi könnte ich bspw. diverse Loggings laufen die durchaus mehr RAM benötigen würden beim abfragen.
bspw für alle Heizkörperthermostate, oder der Wetterstation oder diversen sensoren oder oder oder. -
@igor123 sagte: Vom Master, also vom derzeit laufenden System, alle Instanzen deinstallieren?
Nein, natürlich vom künftigen Slave.
-
@thomas-braun sagte:
bevor der zum 'Nebenhost' degradiert wird.
@paul53 sagte:
vom künftigen Slave.
Wie war das jetzt politisch korrekt?
Ich glaube "secondary Host" -
zweiter Nebenhorst*In
