Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[150d]

Hallo,

ich habe ein Problem mit einem Multihost-System:

Ich hatte bereits zwei ioBroker Nodes verbunden, diese danach aber wieder getrennt. Den Slave wollte ich eigentlich ausrangieren. Auf dem Master war er unter "Hosts" bereits erfolgreich getilgt, den Slave selbst hatte ich einfach abgeschaltet.

Nun brauche ich den Slave aber doch wieder, weil ich Geräte in verschiedenen Netzwerksegmenten habe (eine mDNS-Sache.) Aber ich bringe die Verbindung nicht wieder ans laufen.

Auf dem Master habe ich ausgeführt::

iob stop
iob setup custom
-> war wieder zurück auf JSON
-> jetzt gesetzt auf FILE
iob start

Auf dem Slave habe ich ausgeführt:

iob stop
iob setup custom
-> war noch auf FILE von der alten Multihost-Verbindung
-> jetzt gesetzt auf JSON und 127.0.0.1
-> bestätigt, daß ehemaliges Slave-System zu Single konvertiert werden soll
iob start
-> ioBroker auf dem Slave-Rechner startet als eigene (Single-)Instanz, webUI ist zugreifbar
iob stop
iob setup custom
-> gesetzt auf FILE und <IP_vom_Master>
-> bestätigt, daß daraus ein Slave werden soll
iob start

Jetzt startet der Slave zwar, stellt aber keine Verbindung zum Master-System her. Im Log des Slave steht folgendes:

2023-12-21 23:00:19.318  - info: host.iob-iot iobroker.js-controller version 5.0.17 js-controller starting
2023-12-21 23:00:19.319  - info: host.iob-iot Copyright (c) 2014-2023 bluefox, 2014 hobbyquaker
2023-12-21 23:00:19.319  - info: host.iob-iot hostname: iob-iot, node: v18.19.0
2023-12-21 23:00:19.320  - info: host.iob-iot ip addresses: 10.5.1.51 fe80::b0ec:a8ff:fe51:37ff
2023-12-21 23:00:49.345  - error: host.iob-iot No connection to databases possible, restart
2023-12-21 23:00:49.347  - info: host.iob-iot iobroker _restart
2023-12-21 23:00:49.640  - info: host.iob-iot iobroker Starting node restart.js
2023-12-21 23:00:49.642  - error: host.iob-iot [sendTo] Could not push message "{
  command: 'cmdStdout',
  message: { id: undefined, data: 'Starting node restart.js' },
  from: 'system.host.iob-iot'
}" to "system.host.iob-iot": Cannot read properties of null (reading 'pushMessage')

Habe ich noch etwas vergessen?

[Homoran]

@150d sagte in Multihost hin und her:

Habe ich noch etwas vergessen?

es gab eine Version von ... (hab ich vergessen, admin, controller) da klappte das neu koppeln nicht. bestehende Systeme waren nicht betroffen.
Vielleicht liegt das bei dir vor.

[150d]

@homoran Ja, davon habe ich gelesen - mit v5.0.5 oder sowas. Ich habe inzwischen schon v5.0.17, da hoffte ich, daß das nicht mehr der Fall sei.

Ich glaube, daß sich (mindestens) der Slave noch die alte Authorisierung für die inzwischen gelöste Verbindung gespeichert hat und nun versucht, diese für den neuen Kontakt wieder zu nutzen, während der Master davon schon gar nichts mehr weiß. Wenn das stimmt, müsste ich nur die "Reste" auf dem Slave irgendwie loswerden können. Mit einer Namensänderung des Slaves wäre es wahrscheinlich schon getan, aber das würde ich gerne vermeiden.

[Homoran]

@150d sagte in Multihost hin und her:

nur die "Reste" auf dem Slave irgendwie loswerden können.

mit iob setup custom auf dem Slave.

@150d sagte in Multihost hin und her:

Mit einer Namensänderung des Slaves wäre es wahrscheinlich schon getan

alle verbundenen Geräte müssen unterschiedliche Hostnamen haben.

[150d]

nur die "Reste" auf dem Slave irgendwie loswerden können.
mit iob setup custom auf dem Slave.

Das scheint ja nur umzuschalten, aber nicht zu löschen:

Nachdem ich den Slave "zurück-konfiguriert" hatte auf Single, war wieder das Login-PW aktiv und die Adapter konfiguriert, die schon vorhanden waren, bevor ich ihn damals zum Slave gemacht hatte.

Ich vermute, daß das umgekehrt ebenso ist: Wenn ich ihn jetzt wieder auf Slave konfiguriere, dann wird wieder die Config aktiv, die er in seiner damaligen Slave-Beziehung gehabt hat. Deswegen wird auch nicht nochmal nach Admin-PW des Master gefragt - es ist ja noch eine alte Config da.

alle verbundenen Geräte müssen unterschiedliche Hostnamen haben.

Selbstverständlich. Mein Master heißt "Home", der Slave "iob-iot". Aber das galt halt bereits in der damaligen Beziehung. Wenn ich den Slave jetzt umbenennen würde nach z.B. "iob2", dann würde vermutlich eine völlig neue Beziehung angelegt, anstatt die alte weiterzubenutzen.

[Homoran]

@150d sagte in Multihost hin und her:

Nachdem ich den Slave "zurück-konfiguriert" hatte auf Single, war

zeig mal was du da eigentlich machst.

Ein Slave darf vor der Kopplung keine Instanzen installiert haben

[150d]

@homoran said in Multihost hin und her:

Ein Slave darf vor der Kopplung keine Instanzen installiert haben

Stört aber wohl auch nicht. Wenn ich das richtig verstanden habe, dann wird durch das "iob setup custom" auf eine andere Datenbank (eben FILE statt JSON) umgeschaltet. Wenn es sich um einen Master handelt, werden die alten JSON-Einträge in die neue FILE-DB kopiert, bei einem Slave dagegen nicht, weil der ja später sowieso die DB des Master verwendet.

Was aber in der alten DB schon drinsteht oder nicht wäre im Slave-Fall dann egal, weil diese DB nach dem umschalten sowieso nicht mehr verwendet wird.

Mein Problem wird der umgekehrte Fall sein:

Irgendwo liegt auf dem Slave bereits die Config für eine FILE-DB herum. Das ist die von der alten Master-Slave-Beziehung, die jetzt nicht mehr funktioniert.

Ich müsste nur diese alte Config löschen können, damit beim Umschalten eine neue erstellt wird. Nur weiß ich nicht, wo diese Dateien liegen.

[Homoran]

@150d sagte in Multihost hin und her:

Stört aber wohl auch nicht.

Doch!
die Verwaltung der Instanzen läuft über den Master.
Der weiss davon aber nichts, wenn sie an ihm vorbei installiert wurden.

@150d sagte in Multihost hin und her:

Irgendwo liegt auf dem Slave bereits die Config für eine FILE-DB herum

sicher?
die config siehst du ja beim iob setup custom.
selbst wenn da noch alte Werte drinstehen kannst du diese anpassen.

[150d]

@homoran said in Multihost hin und her:

die Verwaltung der Instanzen läuft über den Master.
Der weiss davon aber nichts, wenn sie an ihm vorbei installiert wurden.

Klar, die Instanzen, die auf dem Slave vor der Verbindung installiert wurden, sind während der Verbindung dann natürlich weg. Wenn ich einen neuen Slave an einen bestehenden Master anflansche, dann erwarte ich auch genau das - daß der Slave die Config des Master übernimmt.

sicher?

... nein. Nicht sicher, war nur ein Erklärungsversuch von mir. Und wie ich inzwischen sagen muß, wahrscheinlich ein nicht zutreffender.

Je mehr ich darüber lese desto mehr befürchte ich, daß ich doch in dem v5.x-no-connect-bug festhänge. :-(

[Homoran]

@150d sagte in Multihost hin und her:

sind während der Verbindung dann natürlich weg.

sind sie leider nicht, nur für den Master unsichtbar.
Wenn man dann irgendwie auf dem Slave updates fahren will, sind identische Adapter auch auf dem Master bezroffen.

Richtig lustig wird es wenn man nach der Kopplu g verducht eine Instsnz, die vorher auf dem Slave existierze, nun für den Admin auf dem Master unsichtbar ist, erneut über den Master auf dem Slave zu installieren.

@150d sagte in Multihost hin und her:

Stört aber wohl auch nicht

stimmt nämlich nicht.

was sagt iob diag auf dem Slave ausgeführt?

[150d]

@homoran said in Multihost hin und her:

So, zweierlei Neuigkeiten.

Erstens: Problem erledigt: :-)

Ich habe jetzt bei "iob setup custom" auf dem Slave einfach einen neuen "Hostname" verwendet, den es zuvor noch nie gab. Daraufhin funktionierte die Verbindung auf Anhieb.

Es muß also doch beim vorherigen Löschen der alten Verbindung irgendetwas übriggeblieben sein.

sind sie leider nicht, nur für den Master unsichtbar.
Wenn man dann irgendwie auf dem Slave updates fahren will, sind identische Adapter auch auf dem Master bezroffen.

Richtig lustig wird es wenn man nach der Kopplu g verducht eine Instsnz, die vorher auf dem Slave existierze, nun für den Admin auf dem Master unsichtbar ist, erneut über den Master auf dem Slave zu installieren.

Zweitens: Das ist sehr gut, daß Du das sagst, vielen Dank! Solche Fälle hatte ich nämlich damals während meines ersten Multihost-Setups tatsächlich beobachtet. Ich wusste damals nur nicht, daß es an diesen "Schatteninstanzen" lag.

Was würdest Du mir denn jetzt vorschlagen?

Ich habe jetzt den Slave wieder mit dem Master verbunden (siehe oben), auf dem Slave waren zuvor aber noch drei Adapter installiert (Admin, Backup und Homekit-Controller). Kann ich die jetzt noch deinstallieren, wo der Slave schon mit dem Master verbunden ist? Oder deinstalliert sich dann die Instanz auf dem Master gleich mit?

[Homoran]

@150d sagte in Multihost hin und her:

Kann ich die jetzt noch deinstallieren,

eben nicht!

dann sind

@homoran sagte in Multihost hin und her:

sind identische Adapter auch auf dem Master betroffen.

[150d]

@homoran

Das heißt: Slave wieder trennen, Adapter deinstallieren, neu verbinden?

Sch... :-)

[Homoran]

@150d sagte in Multihost hin und her:

Ich habe jetzt bei "iob setup custom" auf dem Slave einfach einen neuen "Hostname" verwendet, den es zuvor noch nie gab. Daraufhin funktionierte die Verbindung auf Anhieb.
Es muß also doch beim vorherigen Löschen der alten Verbindung irgendetwas übriggeblieben sein.

möglicherweise in deinem Router

[Homoran]

@150d sagte in Multihost hin und her:

Das heißt: Slave wieder trennen, Adapter deinstallieren, neu verbinden?

ja

[150d]

@homoran said in Multihost hin und her:

möglicherweise in deinem Router

Nein: Ich habe nur den Namen der ioBroker-Instanz (der bei "iob setup custom" abgefragt wird) geändert, nicht den Hostname des Systems.

[150d]

@homoran
Soll ich den Admin-Adapter auf dem Slave auch löschen vor der Verbindung mit dem Master?

[Homoran]

@150d nochmal:

@homoran sagte in Multihost hin und her:

zeig mal was du da eigentlich machst.

https://forum.iobroker.net/topic/51555/hinweise-für-gute-forenbeiträge/1