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

[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

[igor123]

@homoran
Ahsoo okay - dachte da wäre sonnst noch was zu machen.
na dann befolge ich mal deine Anleitung und würde mich ggf. hier nochmals rühren.

Danke euch nochmals für die echt schnelle und tolle unterstützung
LG

[Thomas Braun]

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

nur erstmal weniger zum konfigurieren zu haben - das war mein Hintergedanke warum 1:1 kopie

Ich glaube so ganz hast du das noch nicht verstanden.
Der Slave wird leer an den Master angedockt und dann werden Instanzen vom Master auf den neuen Nebenhost verschoben (oder bei einer Adapterneuinstallation direkt dahin installiert). Das hat mit 1:1-Kopie und weniger Konfiguration nichts zu tun.

Deswegen kann man ja auch vor dem andocken die vorinstallierten Adapter (inkl. Admin) auch schon löschen.

[igor123]

@thomas-braun
Ja nur habe ich bereits diverse instanzen und wollte die Geräte nicht neu verbinden müssen sondern einfach so auf den Slave übertragen.

[Homoran]

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

@thomas-braun
Ja nur habe ich bereits diverse instanzen und wollte die Geräte nicht neu verbinden müssen sondern einfach so auf den Slave übertragen.

ääääähhhhm
Bitte alle Informationen auf den Tisch!

Von welchen Geräten redest du?
Da könnte doch etwas sein.

Trotzdem solltest du erst einmal den Raspi, den du als Slave nutzen willst aufsetzen wie ich es schrieb
Dann kanst du dich ja nochmal vor der Kopplung hier melden

[paul53]

@igor123 sagte: wollte die Geräte nicht neu verbinden müssen

Da ein Slave nicht ohne Master funktioniert (gemeinsame Datenbanken auf dem Master), würde ich alles, was funktionieren muss, auf dem Master installieren (incl. piVCCU) und das, was "nice to have" ist, auf dem Slave.

[Homoran]

@paul53 sagte:

@igor123 sagte: wollte die Geräte nicht neu verbinden müssen

Da ein Slave nicht ohne Master funktioniert (gemeinsame Datenbanken auf dem Master), würde ich alles, was funktionieren muss, auf dem Master installieren (incl. piVCCU) und das, was "nice to have" ist, auf dem Slave.

Wie gesagt bin ich was die piVCCU angeht da etwas anderer Meinung.
Was nutzt mir die piVCCU auf dem Master im Stahl-Serverschrank im Keller?

Auch mein zweiter Slave für Smartmeter ist nicht "nice-To-have" muss aber für den Lesekopf im Zählerschrank hängen (ja, inzwischen gäbe es dafür auch andere Lösungen)

Mir gingen vielmehr Instanzen durch den Kopf, an denen noch "Zentralen" per USB angedockt sind.
Aber auch da kann es wegen der Lage notwendig sein diese auf einen Slave zu verlagern

[paul53]

@homoran sagte: Was nutzt mir die piVCCU auf dem Master im Stahl-Serverschrank im Keller?

Wenn der Montageort eine Rolle spielt, muss man natürlich von dem Prinzip abweichen.

[igor123]

@homoran
Ich rede von den diversen Sensoren, leuchten, saugroboter & co welche ich als instanz bereits drinnen habe und dachte die die ich am Slave laufen lassen möchte dort nicht neu konfigurieren zu müssen

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

@igor123 sagte: wollte die Geräte nicht neu verbinden müssen

Da ein Slave nicht ohne Master funktioniert (gemeinsame Datenbanken auf dem Master), würde ich alles, was funktionieren muss, auf dem Master installieren (incl. piVCCU) und das, was "nice to have" ist, auf dem Slave.

Würdest du es auch empfehlen, wenn es so wie bei mir ist? Habe am jetzigen pi den conbeestick per usb, die SSD via USB und hätte dann auch den HMIP Stick per USB - nicht dass die sich irgendwie stören?

Der Montageort wäre mir nicht wichtig, in dem Fall wäre der Slave im selben raum wie der Master

[paul53]

@igor123 sagte: die SSD via USB

Per USB 3, ohne dass Zigbee gestört wird?
Zigbee funkt auf 2,4 GHz, HmIP auf 868 MHz.

[Homoran]

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

Der Montageort wäre mir nicht wichtig, in dem Fall wäre der Slave im selben raum wie der Master

dann stellt sich wirklich die Frage warum bei einem Pi4 mit 8GB RAM noch einen Slave aufbauen

[igor123]

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

@igor123 sagte: die SSD via USB

Per USB 3, ohne dass Zigbee gestört wird?
Zigbee funkt auf 2,4 GHz, HmIP auf 868 MHz.

dem Conbee habe ich ein qualitatives langes USBKabel spendiert und hängt an USB 2.0
SSD ist am 3.0 direkt mit einen kurzen kabel drauf.
wegen störung dachte ich eher dass die SSD dem HMIP-Stick probleme machen könnte da direkt daneben

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

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

Der Montageort wäre mir nicht wichtig, in dem Fall wäre der Slave im selben raum wie der Master

dann stellt sich wirklich die Frage warum bei einem Pi4 mit 8GB RAM noch einen Slave aufbauen

Um eben diverses Logging zu betreiben und dafür nicht den Master-Pi überfordern zu müssen.

[paul53]

@igor123 sagte: die SSD dem HMIP-Stick probleme machen könnte da direkt daneben

Dann spende dem HMIP-Stick auch ein ausreichend langes, gut geschirmtes USB-Kabel.