UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[igor123]

@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

[paul53]

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

[paul53]

@igor123 sagte: iobroker und HMIP auf ein System

Mit piVCCU geht das.

[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

[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

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?