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

[Thomas Braun]

@zolex
Das ist ja der selbe Quark. Hast du ein Backup vom Master auf den künftigen Slave geschoben und denn dann versucht anzubinden?

[Zolex]

@thomas-braun said in Multihost:

@zolex
Das ist ja der selbe Quark. Hast du ein Backup vom Master auf den künftigen Slave geschoben und denn dann versucht anzubinden?

Nein.

[Homoran]

@thomas-braun mich stört die sudo-Passwort Aufforderung beim Master
Da scheint die Master-Installation total krumm zu sein

[Thomas Braun]

@homoran sagte in Multihost:

Da scheint die Master-Installation total krumm zu sein

Ja, aber nicht nur die.

[Thomas Braun]

@homoran sagte in Multihost:

mich stört die sudo-Passwort Aufforderung beim Master

Du meinst die:

ralf@iobroker:/opt/iobroker$ iobroker list instances
[sudo] Passwort für ralf:

Dürfte entweder daran liegen, dass ralf nicht in der Gruppe 'iobroker' ist oder es keinen User 'pi' mehr gibt.

[Homoran]

@Zolex
Allerletzte Idee:

bei beiden Systemen:

iobroker stop
iobroker upload all
iobroker start

Und wieder den Master vor dem Slave starten

[Homoran]

@thomas-braun sagte in Multihost:

Du meinst die:

jepp

[Zolex]

@homoran said in Multihost:

@Zolex
Allerletzte Idee:

bei beiden Systemen:

iobroker stop
iobroker upload all
iobroker start

Und wieder den Master vor dem Slave starten

Ich hab es für beide Systeme so gemacht und den Master vor dem Slave gestartet.
Leider das gleiche Ergebnis.

[Zolex]

@zolex
Ich merke, dass Wir nicht weiter kommen.

Ich werde beide Systeme neu aufsetzen und nochmal anfangen.
Bei Problemen melde ich mich wieder.

[Zolex]

@zolex
Nach dem ich alles neu aufgesetzt habe und das Multihost gestartet habe, hab ich sowohl auf dem Master als auch auf dem Slave zugriff auf den Master und der Slave ist nicht mehr zu sehen.
Das versteh ich jetzt überhaupt nicht mehr.

[Thomas Braun]

@zolex

Ich habe das heute Nachmittag mal versucht nachzustellen, deine Beobachtung kann ich bestätigen. Der Master rutscht auf den vorgesehenen Slave.
Ich konnte es aber noch nicht weiter eingrenzen, woran das liegt.

@apollon77
Beide Systeme zuerst auf gleichen Stand gebracht (iob -version 3.3.20 mit redis) und dann versucht zu verheiraten.

[Homoran]

@zolex sagte in Multihost:

Das versteh ich jetzt überhaupt nicht mehr.

Da bist du nicht allein!

Das muss sich @apollon77 vielleicht ansehen.
Da sollten wir im Moment nichts kaputtspielen

[Zolex]

@homoran said in Multihost:

@zolex sagte in Multihost:

Das versteh ich jetzt überhaupt nicht mehr.

Da bist du nicht allein!

Das muss sich @apollon77 vielleicht ansehen.
Da sollten wir im Moment nichts kaputtspielen

Ja, hab ich verstanden.
Ich warte jetzt mal ab, ob @apollon77 sich meldet.

[apollon77]

Mmeeeehhhhhh ... ja der 3.3.20 fix war blödsinn ... es gibt nachher ne 3.3.21

[apollon77]

Ok, 3.3.21 sollte das Fixen und ist stable getaggt. Also botte am besten mal ganz frisch aufsetzen

[Thomas Braun]

@apollon77

Ich konnte jetzt ein Multihost-System frisch aufsetzen, 3.3.21 funktioniert also wieder.

Da gleich eine Frage dazu, weil ich das so nicht finden konnte:
Den sekundären Host habe ich jetzt ohne jeglichen Adapter angeflanscht, also auch ohne admin. Wird das funktionieren oder war ich zu eifrig im entschlacken?

In der Doku steht zwar

Es ist daher sinnvoll für einen Slave einen Host mit Minimalinstallation zu verwenden, also nur den js-controller und den admin.

es scheint aber auf den ersten Blick sogar ohne diese beiden zu gehen.

[apollon77]

@thomas-braun also generell vergisst der Slave Host sobald er dazu gemacht wird eh alle Instanzen von installierten Adaptern. Heißt das Admin, Discovery und backitup zwar weiter Code seitig installiert sind aber keine Instanzen mehr da sind. Ob man jetzt zu den dreien wieder eine Instanz auf dem Slave anlegt liegt beim User. Für Discovery und backitup kann das Sinn machen wenn man diese Funktionen nutzen will auf dem Slave für lokale Dinge. Admin bringt nur einen Vorteil wenn man - egal welche ip man aufruft - ne Admin ui haben will. Man muss dann aber manuell die konfig dieser Admin instanzen immer in sync halten.

[Homoran]

@apollon77 Danke für das Update!

Dann bin ich der Meinung dass die Empfehlung heissen sollte, dass auf dem Slave vor der Kopplung gar keine Instanz mehr existieren sollte.

Ansonsten kommt (kam??) es zu der Meldung, dass eine Version veraltet sei, und der User findet sie nicht.

[apollon77]

@homoran Äpfel und Birnen

EIn neu eingerichteter Slave hat immer Admin, Discovery und Backitup installiert auf "Code" ebene. Sobald man Ihn zum SLave macht sind die Instanzen für diese 3 Adapter zwar weg aber der "Code" === "Dateien" liegen noch da. Das müsste man manuell deinstallieren damit es keine "da liegen alte Admin Files rum" Meldung bekommt

[Thomas Braun]

@apollon77 sagte in Multihost:

EIn neu eingerichteter Slave hat immer Admin, Discovery und Backitup installiert auf "Code" ebene.

Dann wäre das 'genaueste Vorgehen' dann meins? Also dem frisch geschlüpften ioBroker auch noch die voreingestellten Adapter abnehmen und nur die leere Hülle an den Master andocken?