Multihost läuft, aber Fehler im Log
-
Jupp. Der Fehler hieß ja auch EADDRINUSE:50005. Da war eine Port-Adresse schon in Benutzung, was auf einen doppelten Aufruf hinweist. Super, dass es jetzt klappt.
-
Hallo dewenni,
wo war denn bitte der Trick bei der multihost Einrichtung? Ich führe seit Stunden immer wieder die Anweisung von der iobroker-Seite, also:
1. Man gibt beim Master nur noch ein: sudo iobroker multihost enable
2. Anschließend auf dem slave: sudo iobroker multihost browse
3. Jetzt müssten vorhandene Master angezeigt werden.
4. Daraufhin wird mit sudo iobroker multihost connect der entsprechenden Master ausgewählt
5. Damit ist die Multihost-Verbindung fertig.
Ich komme immer bis zum 4. Schritt (auf dem slave). Der läuft scheinbar durch. Leider ist aber dann meine iobroker-Installation auf dem slave platt, d.h. ich komme per webbrwoser nicht mehr auf die Oberfläche. Auch iobroker restart o.ä. in der Konsole bringt dann nichts mehr. Ich musste dann die SD-Karte jeweils plätten und immer ganz von vorne beginnen. Jetzt nervt es langsam…
Ach übrigens: mein Host gibt nun im Log immer folgende Fehlermeldung aus, cih glaube so ähnlich wie bei Dir:
host.raspberrypi 2019-01-26 18:25:26.834 error multihost service error: Error: bind EADDRINUSE 0.0.0.0:50005 at _handle.lookup (dgram.js:266:18) at _combinedTickCallback (internal/process/next_tick.js:142:11) at process._tickCallback (
Wie genau hast Du bitte diesen Fehler behoben?
Und hat noch Jemand vielleicht einen Tipp, wie ich den multihost-Modus hinbekomme?
Danke und Gruß
Erol
-
Und noch folgende Beobachtung: Wenn ich multihost auf dem host enable, kommt im Log der folgende Eintarg:
host.raspberrypi 2019-01-26 18:33:30.700 warn Host on this system is not possible, because IP address is for states is 0.0.0.0.
Ich kann aber trotzdem auf dem slave den host finden und mich (scheinbar?) verbinden, nur eben leider mit iobroker-Absturz.
-
Leider ist aber dann meine iobroker-Installation auf dem slave platt, d.h. ich komme per webbrwoser nicht mehr auf die Oberfläche. `
Das ist korrekt so!Die Administration des Slaves findet über den Admin des Masters statt.
Auch iobroker restart o.ä. in der Konsole bringt dann nichts mehr. `
Wie hast du ioBroker installiert?wenn du diese mit dem neuen Installer vor mehr als 2 Wochen gemacht hast, musst du mit
sudo systemctl iobroker restartmachen.
Inzwischen geht der alte Befehl wieder, der neue ist aber immer möglich.
Gruß
Rainer
-
Danke Rainer,
wieder etwas dazu gelernt. Ich habe nun also noch einmal den alle Schritte wiederholt. Der slave ist nun wieder nicht direkt der webbrowser ansprechbar, die connection ist angeblich enabled, aber ich sehe den slave nicht unter "hosts" auf dem host.
Jetzt kommt die Krönung: weil der cloud Adapter auf dem Master anfing herumzuzicken, wollte ich mit "iobroker restart" auf dem master das Ganze nue starten. Jetzt ist auch diese Kiste nicht per Webbrowser erreichbar, per Konsole antwortet der Pi aber schon.
Iobroker habe ich stumpf nach der Anleitung auf der Homepage von iobroker installiert.
Ich mach mich ma so langsam an die gefühlt 23. Installation heute. Auf dem Master-Pi ist halt nur mehr drauf und das wird länger dauern.
Melde mich wieder, wenn ich irgendeinen Erfolg zu melden habe.
Gruß
Erol
-
Iobroker habe ich stumpf nach der Anleitung auf der Homepage von iobroker installiert. `
Da gibt/gab es zwei verschiedenesiehe hier:
http://www.iobroker.net/docu/?page_id=8323&lang=de
incl. der Hinweise
Gruß
Rainer
-
Hallo Rainer,
ich habe den neuen Weg genommen, nicht den der unter "Installation ioBroker (alter Weg / optional)".
Mittlerweile läuft mein master-pi inkl. iobroker und allen Adapter wieder.
Beim eintippen von````
iobroker multihost statusauf dem master :pi@raspberrypi:~ $ iobroker multihost status
Nothing changed.Miltihost: enabled
Authentication: enabled
Objects: file on 0.0.0.0
States: file on 0.0.0.0
pi@raspberrypi:~ $auf dem slave:pi@raspberrypi:~ $ iobroker multihost status
Nothing changed.Miltihost: enabled
Authentication: enabled
Objects: file on 192.168.178.55
States: file on 192.168.178.55
pi@raspberrypi:~ $Der Pi mit 192.168.178.55 ist mein Master, sollte doch also eigentlich alles gut sein, oder? Leider sehe ich den slave unter "hosts" aber nicht. Zum Mäuse melken. -
Problemlösung gefunden: Bei den x-fachen (unnötigen) Neuinstallationen habe ich vergessen, den hostnamen des slave zu ändern. Somit hatte der den Standardnamen, genau wie mein master-Pi.
Namen des slave geändert –> alles läuft wie es soll.
Vielen Dank für Eure Hilfe.
-
Guten Morgen,
ich (leierder) schon wieder. Anscheinend ist der Fehler laut Log
host.raspberrypi 2019-01-27 11:44:04.844 error multihost service error: Error: bind EADDRINUSE 0.0.0.0:50005 at _handle.lookup (dgram.js:266:18) at _combinedTickCallback (internal/process/next_tick.js:142:11) at process._tickCallback (wohl doch Ursache größeren Übels. Ich konnte zwar von meinem Master aus einen Adapter auf meinem slave installieren, der auch mit 'grün' in der Übersicht angezeigt wird. Es fehlen jedoch die zugehörigen Objekte, die dieser anlegen müsste. Ich vermutete zunächst, es läge am Adapter, aber es wohl doch die Fehlermeldung (s.o.).
Mit dem Tipp von dewenni weiter oben, d.h.
iobroker setup custom ````ausführen, komme ich nicht weiter. Obwohl ich in dem auf diesen Befehl folgenden Dialog die Ip-Adresse des Masters eingebe, taucht der Fehler mit "EADDRINUSE" im Log weiterhin auf. Danke im Voraus für Eure Hilfe. Erol -
Was läuft denn bei dir auf port 50005????
-
Sorry für die doofe Frage, aber wie finde ich das heraus? Bin kein Experte…
-
Was hast du denn außer ioBroker noch auf dem Master oder Slave installiert?
Der Smartmeter-Adapter legt die Objekte erst an, wenn er wirklich funktioniert, also korrekt konfiguriert ist.
Vorher existiert da nichts
Bitte nicht in diversen Threads mit dem selben Inhalt posten.
Gruß
Rainer
-
Au dem Slave läuft nur Smartmeter.
Auf dem Master diese hier:
18600_unbenannt.png -
Laufen da keine anderen Programme außer ioBroker?
wenn nein, dann mal bitte beide rebooten.
Erst den Master, dann den Slave
Gruß
Rainer
-
Auf beiden Systemen läuft jeweils nur iobroker.
Habe nun beide rebootet. War's noch nicht.
Anschließend smartmeter-Adapter vom slave deinstalliert und wieder neu installiert –> keine Fehlermeldung mehr im Log.
Die Objekte von smartmeter sehe ich zwar immer noch nicht, aber das ist offtopic (oder?).
Danke Rainer.
-
Ja!
da machst du bitte im anderen Thread weiter
-
Hi,
das ist zwar ein alter Thread aber ich hänge mich hier mal rein. Mein System (Master plus 2 Slaves) lief bislang sehr stabil, seit heute hatte ich aber auch die hier genannten Log Errors (Multihost discovery server: error: Error: bind EADDRINUS...), wobei die Objekte auf den Slaves noch sauber angezeigt und auch verarbeitet wurden.
Dies ist nach einem Update des "script engine" Adapters auf die 4.6.14 aufgetreten. Ein einfacher Neustart des Masters aus der Admin Oberfläche heraus hat nix gebracht, ich hab den Master dann "hart" neu gestartet (sudo shutdown -r 0), seitdem läuft es wieder stabil.
Keine Ahnung ob es wirklich am Javascript-Update lag oder ob das Zufall war.Alle Raspis haben:
node.js v12.16.3
NPM 6.14.4
js-controller 3.1.4 -
Hi zusammen,
ich habe diesen Fehler leider auch in meiner Installation.
host.iobrokerGen2Revival 2020-07-23 11:57:11.646 error at processTicksAndRejections (internal/process/task_queues.js:85:21) host.iobrokerGen2Revival 2020-07-23 11:57:11.646 error at dgram.js:338:20 host.iobrokerGen2Revival 2020-07-23 11:57:11.646 error Multihost discovery server: error: Error: bind EADDRINUSE 0.0.0.0:50005Scheinbar löst ein Restart von iobroker über die Konsole vorübergehend das Problem, es taucht aber mit der Zeit wieder auf.
Der Master läuft in einer Dockerinstallation (ausschließlich iobroker in diesem Docker), der Slave ist ein Pi, ebenfalls nur mit iobroker.node.js v12.18.2
NPM 6.14.5
js-controller 3.1.6Master und Slave werden aks Host grün angezeigt. Jemand eine Idee?
VG
-
@Coffeelover Siehe Antwort weiter oben, der Fehler sagt dass da eine Adresse bereits "in use" ist. Das klingt nach einer Instanz die 2mal gestartet wurde. Ich hatte das Problem auch und es erst mit einem Re-Start der Raspberrys hinbekommen (sudo shutdown -r 0)
