Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[igor123]

@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 :-D

[paul53]

@igor123 sagte: der neue PI4 mit nur PIVCCU drauf langweilen

Weshalb nicht piVCCU auf dem bestehen ioBroker-Pi 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 :-D

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