Kopie von ioBroker auf einen Slave-RPI 4

Homoran

@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 custom ausführen und die IP des Masters als Speicherort eingeben
Erst Master, dann Slave rebooten
- jetzt müsste das Multihostsystem stehen
über den admin des Masters die Instanzen auf den Slave verschieben

igor123

@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.

Homoran

@paul53 sagte:

Weshalb nicht piVCCU auf dem bestehen ioBroker-Pi 4?

Bei mir war es wegen der besseren Position

paul53

@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.

igor123

@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...

Thomas Braun

@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.

Homoran

@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

Homoran

@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!

Thomas Braun

@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.

igor123

@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.

paul53

@igor123 sagte: Vom Master, also vom derzeit laufenden System, alle Instanzen deinstallieren?

Nein, natürlich vom künftigen Slave.

Homoran

@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"

Thomas Braun

@homoran

zweiter Nebenhorst*In

Homoran

Ich kann mich da auch noch nicht dran gewöhnen und benutze noch Slave

@thomas-braun sagte in Kopie von ioBroker auf einen Slave-RPI 4:

@homoran

zweiter Nebenhorst*In

das sind dann Nebenhostende

igor123

@homoran sagte in Kopie von ioBroker auf einen Slave-RPI 4:

Ich kann mich da auch noch nicht dran gewöhnen und benutze noch Slave

@thomas-braun sagte in Kopie von ioBroker auf einen Slave-RPI 4:

@homoran

zweiter Nebenhorst*In

das sind dann Nebenhostende

na gut, dann haben wir das zumindest geklärt

Also ist eine Kopie des derzeitigen PI's auf den neuen PI nicht einfach so möglich?
Oder soll ich lieber den neuen PI als aktiven Backup nutzen, dass bei Ausfall automatisch der neue PI genutzt wird? ist sowas überhaupt möglich?

Thomas Braun

@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:

Also ist eine Kopie des derzeitigen PI's auf den neuen PI nicht einfach so möglich?

Wozu soll das dienen? Das ist ja dann kein Multihost mehr.

Oder soll ich lieber den neuen PI als aktiven Backup nutzen, dass bei Ausfall automatisch der neue PI genutzt wird? ist sowas überhaupt möglich?

Ja, das ist auch möglich. Hab mir das auch mal angeschaut als ich den 'Nebenhostenden' rausgeworfen habe. Das ganze Setup war mir dann aber zu komplex.

Andreios

@igor123 said in Kopie von ioBroker auf einen Slave-RPI 4:

@paul53 sagte in Kopie von ioBroker auf einen Slave-RPI 4:

Da ich den Pi 4 zu Weihnachten erhalten habe und für etwas nutzen will.

Na, da fallen mir aber andere Dinge ein, für die ich den noch nutzen könnte, als "nur so" einem unterbeschäftigten RPi noch einen weiteren noch mehr unterbeschäftigten RPi zur Seite zu stellen!

Homoran

@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:

Also ist eine Kopie des derzeitigen PI's auf den neuen PI nicht einfach so möglich?

Warum?
das ist dann kein Multihost, sonder eine eigenständige Installation
Bei einem Multihost muss und wird alles über den Admin des primären Hosts (aka Master) administriert

igor123

@homoran sagte in Kopie von ioBroker auf einen Slave-RPI 4:

@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:

Also ist eine Kopie des derzeitigen PI's auf den neuen PI nicht einfach so möglich?

Warum?
das ist dann kein Multihost, sonder eine eigenständige Installation
Bei einem Multihost muss und wird alles über den Admin des primären Hosts (aka Master) administriert

Nein nein natürlich dann auf Multihost Umstellen
nur erstmal weniger zum konfigurieren zu haben - das war mein Hintergedanke warum 1:1 kopie

Homoran

@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:

nur erstmal weniger zum konfigurieren zu haben

du hast nach dem wie ich es beschrieben habe gar nichts zu konfigurieren.
Du weist nach der Erstellung der Multihostumgebung über den Admin mit nur einem(?) Klick nur einen anderen Host zu

NEWS