Multihost - Master in Synology Docker, Slave RPI - jsonl?
-
Google durch meine Signatur...
-
@sebhoff sagte in Multihost - Master in Synology Docker, Slave RPI - jsonl?:
google gerade
wofür?
wozu hat @Thomas-Braun seine Signatur?
-
-
@thomas-braun said in Multihost - Master in Synology Docker, Slave RPI - jsonl?:
sudo ss -lp | grep 9001
Sowohl die Docker shell als auch die Synology shell können mit ss nichts anfangen.
-
@sebhoff sagte in Multihost - Master in Synology Docker, Slave RPI - jsonl?:
nichts anfangen.
sudo netstat -ntlp | grep LISTEN -
@glasfaser said in Multihost - Master in Synology Docker, Slave RPI - jsonl?:
sudo netstat -ntlp | grep LISTENroot@buanet-iobroker1:/opt/iobroker# sudo netstat -ntlp | grep LISTEN tcp 0 0 0.0.0.0:1889 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:6052 0.0.0.0:* LISTEN - tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN - tcp 0 0 127.0.0.1:9001 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:1880 0.0.0.0:* LISTEN - tcp6 0 0 :::8081 :::* LISTEN - tcp6 0 0 :::8087 :::* LISTEN - -
-
@glasfaser said in Multihost - Master in Synology Docker, Slave RPI - jsonl?:
sudo netstat -ltp
root@buanet-iobroker1:/opt/iobroker# sudo netstat -ltp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:1889 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:6052 0.0.0.0:* LISTEN - tcp 0 0 localhost:9000 0.0.0.0:* LISTEN - tcp 0 0 localhost:9001 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:1880 0.0.0.0:* LISTEN - tcp6 0 0 [::]:8081 [::]:* LISTEN - tcp6 0 0 [::]:8087 [::]:* LISTEN - -
Lüppt überhaupt etwas auf deinem iobroker !?
So bei mir
root@iobroker:/opt/iobroker# sudo netstat -ntlp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN 204/iobroker.js-con tcp 0 0 127.0.0.1:9001 0.0.0.0:* LISTEN 204/iobroker.js-conEdit ...
Log gekürzt -
@glasfaser said in Multihost - Master in Synology Docker, Slave RPI - jsonl?:
Lüppt überhaupt etwas auf deinem iobroker !?
-
Kann mir gerade kein Reim daraus machen ... auch in der Ausgabe iob diag
wird kein Pid angezeigt
Mhh...EDIT :
bei der Raspberry schon !!
-
@thomas-braun said in Multihost - Master in Synology Docker, Slave RPI - jsonl?:
Hast du auf nodejs@18 umgestellt?
Besser?
pi@raspberrypi:/opt/iobroker $ uname -m && type -P nodejs node npm npx && nodejs -v && node -v && npm -v && npx -v && iob -v && whoami && groups && echo $XDG_SESSION_TYPE && pwd && sudo apt update &> /dev/null && sudo apt update && apt policy nodejs aarch64 /usr/bin/nodejs /usr/bin/node /usr/bin/npm /usr/bin/npx v18.16.0 v18.16.0 9.5.1 9.5.1 4.0.24 pi pi adm dialout cdrom sudo audio www-data video plugdev games users input render netdev lpadmin gpio i2c spi iobroker tty /opt/iobroker Hit:1 http://raspbian.raspberrypi.org/raspbian bullseye InRelease Hit:2 http://archive.raspberrypi.org/debian bullseye InRelease Hit:3 https://repos.influxdata.com/debian stable InRelease Hit:4 https://deb.nodesource.com/node_18.x bullseye InRelease Hit:5 https://repos.influxdata.com/debian bullseye InRelease Reading package lists... Done Building dependency tree... Done Reading state information... Done All packages are up to date. nodejs: Installed: 18.16.0-deb-1nodesource1 Candidate: 18.16.0-deb-1nodesource1 Version table: *** 18.16.0-deb-1nodesource1 500 500 https://deb.nodesource.com/node_18.x bullseye/main armhf Packages 100 /var/lib/dpkg/status 12.22.12~dfsg-1~deb11u4 500 500 http://raspbian.raspberrypi.org/raspbian bullseye/main armhf Packages -
-
@glasfaser
Danke für den Tipp. Das muss ich dann auf morgen verschieben... -
So - es ist morgen, aber nachdem ich nun schon viele Stunden erfolglos verschwendet habe, werde ich wohl erst mal eine Pause einlegen. Ich bereue inzwischen ein wenig den Umstieg auf die Synology - das bringt eine ganze Reihe an Komplikationen, die ich nicht erwartet hatte. Ich will doch eigentlich nur den ESPhome-Adapter benutzen und entweder einen bereits geflashten ESP8266 "adoptieren" oder diesen direkt vom ESPhome Adapter aus flashen. USB an Docker durchreichen habe ich bald aufgegeben, adoptieren funktioniert nicht, weil das Ding in einem anderen Subnetz ist und anscheinend nicht gefunden wird und Multihost ist wie man sieht auch eine Herausforderung. <seufz>
Am Wochenende treffe ich wahrscheinlich einen Kollegen, der in der Thematik weitaus besser bewandert ist als ich und dann versuchen wir es hoffentlich zusammen nochmals. Vielleicht melde ich mich dann noch mit weiteren Fragen. Auf jeden Fall schon mal vielen Dank für die Unterstützung, die ich hier bekommen habe! -
@sebhoff sagte in Multihost - Master in Synology Docker, Slave RPI - jsonl?:
Ich bereue inzwischen ein wenig den Umstieg auf die Synology - das bringt eine ganze Reihe an Komplikationen, die ich nicht erwartet hatte.
Und aus diesem Grund setze ich sowas auch nicht ein. Ist mir durch die 'Andersartigkeit' von Docker-Containern zu komplex.
-
So - bin etwas weiter. Ich hatte übersehen, dass für den Container die beiden Ports 9000 und 9001 für TCP und nicht für UDP geöffnet waren.
Nach der entsprechenden Änderung kam dann folgende Fehlermeldung auf dem Slave:
pi@raspberrypi:~ $ iobroker multihost connect Server Cannot start inMem-states on port 9000: Failed to lock DB file "/opt/iobroker/iobroker-data/states.jsonl"!Nachdem ich auf dem Raspi nun auch noch den Desktop ausgestellt habe, sieht es so aus:
pi@raspberrypi:~ $ iobroker multihost connect No connection to databases possible ...Ich werte das mal als Fortschritt.
Werde nun erst mal meinem regulären Job etwas Zeit widmen müssen. Falls jemand auf Anhieb sieht, wo das Problem nun liegen könnte, freue ich mich über Input. Ansonsten werde ich es heute Abend weiter versuchen (oder mal in einer Pause...)
-
Interessant - wenn ich einen Neustart von iobroker im Master mache, finde ich nun folgenden Eintrag im Log:
host.buanet-iobroker1-Server 2023-06-19 10:57:48.447 error Cannot start inMem-objects on port 9001: Failed to lock DB file "/opt/iobroker/iobroker-data/objects.jsonl"!Iobroker läuft aber, ist problemlos erreichbar und tut was getan werden soll. Bin wieder mal verwirrt...
-
So - ich wollte noch kurz berichten, dass ich inzwischen mein Ziel erreicht habe: ich kann nun meine ESP8266s in ioBroker auf der Synology integrieren. Allerdings anders als ursprünglich geplant. Falls jemand mal ähnliche Probleme hat, hier ist meine Lösung:
Nachdem ich mit der Multihost-Lösung nicht weiterkam, habe ich weiter versucht, einen via https://web.esphome.io/ vorbereiteten ESP8266 in ESPhome auf der Synology nach dessen automatischer Erkennung zu "adoptieren". Dies scheiterte jedoch an der Tatsache, dass hierfür die mDNS services laufen müssen - und den dafür benötigten Port 5353 konnte ich nicht in den Container durchreichen. An den Firewall-Einstellungen lag es nicht - auch ohne FW bestand das Problem weiter.
Blieb am Schluss noch, einen auf einem anderen System (dem Raspberry Pi) vollständig konfigurierten ESP8266 manuell zur ESPhome-Installation auf der Synology hinzuzufügen. Mit viel trial und error habe ich dann gemerkt, dass ich dafür in der Synology firwewall die IPs des Subnetzes freigeben musste. Anschließend konnten grundsätzlich via https://web.esphome.io/ vorbereitete ESP8266s manuell hinzugefügt werden. Zunächst verwirrend war, dass dieses hinzugefügte Gerät dann nicht im ESPhome Dashboard erscheint - aber das ist anscheinend normal (und irrelevant, da die Sensor-Werte an ioBroker gesendet werden).
Das war aber immer noch nicht die endgültige Lösung, da ich auch mit dem ESPhome-Adapter in ioBroker auf meinem Raspberry verschiedene Probleme hatte, die Sache richtig zum Laufen zu bringen. Schließlich habe ich dann Home Assistant auf dem Raspberry laufen lassen und von dort im ESPhome-Adapter die ESP8266s konfiguriert.
Das letzte Problem war dann, dass diese auf einmal nicht mehr im Netz zu erreichen waren - ping lief, aber sonst nicht viel. Nach einigen weiteren Stunden Zeitverschwendung habe ich dann herausgefunden, dass hierfür der ESP web server installiert werden muss. Danach gab es nur noch ein paar vergleichsweise kleine Probleme zu beheben - zum Beispiel ein kryptischer "Bad format. Expected 0 at the begin"-Fehler.
So - und nun sieht es nach gefühlt 150 Stunden Frustration endlich so aus:
Der Log weist weiterhin auf gewisse Probleme hin - der ESP8266 scheint sich regelmäßig zu verabschieden und der "Expected 0 at the begin"-Fehler ist irgendwie auch noch da. Da muss ich also noch ein wenig weitersuchen:
esphome.0 2023-06-30 11:12:36.233 warn Client 192.168.178.75 Timeout, connection Lost, will reconnect automatically when device is available! esphome.0 2023-06-30 11:12:36.214 warn Client 192.168.178.75 Timeout, connection Lost, will reconnect automatically when device is available! esphome.0 2023-06-30 11:12:31.853 error ESPHome error handling issue 192.168.178.89 TypeError: Cannot read properties of undefined (reading 'ip') esphome.0 2023-06-30 11:12:31.260 error ESPHome client 192.168.178.75 Error: Bad format. Expected 0 at the begin esphome.0 2023-06-30 11:12:31.244 error ESPHome client 192.168.178.75 Error: Bad format. Expected 0 at the beginNochmals herzlichen Dank für die Unterstützung hier!
