Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[apollon77]

@mick70 ok. Hättest du mal früher gefragt ;-)) an sich muss NIEMAND iobroker neu installieren wenn ein Adapter nicht tut. Komplett unnötig ;-)

Generell rechte ändern ist ne blöde Idee. „iob fix“ bitte laufen lassen das das alles korrigiert wird.

Wenn Connection refused kommt auf dem Web Port dann sollten wir dort mal beim Web Adapter anfangen. Was ist dein Status? Was sagt das log wenn du den restartest?

Strukturierte Fehlversuche und kein try and error Prinzip.

[mick70]

@thomas-braun

1. Das ist kein systemweiter "root login", der User root ist im System sogar totgelegt. Root erscheint da, weil iobroker in einem Docker Container läuft, der halt so wie vom Entwickler vorgeschlagen über dessen Skript eingerichtet wurde. Die Bilder sind aus einer Bash-Shell, ohne die man bei Docker ja gar keine Shell hätte.

2. Zwischendrin war der Container wegen 777 exponiert, richtig. Macht man nicht, richtig. Deshalb ist der alte Container weg, nachdem die hier im Forum (!) vorgeschlagene Maßnahme keinen Erfolg gebracht hat. Deshalb Docker, man experimentiert halt leichter.

3. Was spricht so dramatisch gegen die 2GB? Geht gar nicht? Soll ich besser wieder gehen, weil die 8GB im Moment in Gold aufgewogen werden?

4. Die folgenden Prozesse bleiben nach einem "iobroker stop" offen und verhindern den fix:

root@22b3c96e22ae:/opt/iobroker# iobroker stop
iobroker controller daemon is not running
root@22b3c96e22ae:/opt/iobroker# iobroker fix
library: loaded
Library version=2021-12-27
ioBroker or some processes are still running:
 io.admin.0
 io.javascript.0
 io.history.0
 io.ping.0
 io.hue.0
 io.discovery.0
 io.backitup.0
 io.iot.0
 io.jarvis.0
 io.info.0
 io.cloud.0
 io.web.0
Please stop them first and try again!
root@22b3c96e22ae:/opt/iobroker#

Ansonsten, vielen Dank für den freundlichen Empfang ;)

[Thomas Braun]

@mick70
Installier's halt nativ, ein Container bringt dir an der Stelle gar nix.

ps aux | grep ^io.

liefert?

[mick70]

@apollon77

Hach, ja... Lief nebenher, deshalb wars nicht zu dramatisch.

Im Log steht beim Einschalten von Web (danach "grüne" Instanz):

web.0
2022-02-08 20:06:02.565	info	http server listening on port 8082

web.0
2022-02-08 20:06:02.560	info	socket.io server listening on port 8082

web.0
2022-02-08 20:06:02.309	info	starting. Version 3.4.13 in /opt/iobroker/node_modules/iobroker.web, node: v14.19.0, js-controller: 3.3.22
host.22b3c96e22ae
2022-02-08 20:06:00.410	info	instance system.adapter.web.0 started with pid 7168
host.22b3c96e22ae
2022-02-08 20:06:00.252	info	"system.adapter.web.0" enabled

Wenn ich von der Übersicht her versuche, VIS zu öffnen, kommen noch folgende Fehler, die ich so bisher noch nicht gesehen hatte:

URIError: Failed to decode param '%web_protocol%://192.168.178.98:%web_port%/vis/edit.html'
    at decodeURIComponent (<anonymous>)
    at decode_param (/opt/iobroker/node_modules/express/lib/router/layer.js:172:12)
    at Layer.match (/opt/iobroker/node_modules/express/lib/router/layer.js:148:15)
    at matchLayer (/opt/iobroker/node_modules/express/lib/router/index.js:580:18)
    at next (/opt/iobroker/node_modules/express/lib/router/index.js:220:15)
    at expressInit (/opt/iobroker/node_modules/express/lib/middleware/init.js:40:5)
    at Layer.handle [as handle_request] (/opt/iobroker/node_modules/express/lib/router/layer.js:95:5)
    at trim_prefix (/opt/iobroker/node_modules/express/lib/router/index.js:323:13)
    at /opt/iobroker/node_modules/express/lib/router/index.js:284:7
    at Function.process_params (/opt/iobroker/node_modules/express/lib/router/index.js:341:12)

Mir sagt das leider wenig, nachdem die Instanzen ja alle grün sind?

[mick70]

@thomas-braun

Wahrscheinlich hast du recht mit der nativen Installation. Nachdem jetzt alle Adapter außer VIS rennen, fänd' ichs halt ... naja, anstrengend ;)

Ja, ps aux liefert mehr:

root@22b3c96e22ae:/opt/iobroker# ps aux | grep ^io.
iobroker    94  7.7  5.6 225912 109124 ?       Sl   18:11   9:21 iobroker.js-controller
iobroker   116  1.2  4.0 192904 78076 ?        Sl   18:11   1:27 io.admin.0
iobroker   131  1.2  5.2 216628 101324 ?       Sl   18:12   1:34 io.javascript.0
iobroker   160  0.2  2.9 175144 56844 ?        Sl   18:12   0:16 io.history.0
iobroker   175  0.2  2.8 169396 55532 ?        Sl   18:12   0:18 io.ping.0
iobroker   193  4.4  3.4 175520 66312 ?        Sl   18:12   5:18 io.hue.0
iobroker   208  0.1  2.8 168292 54188 ?        Sl   18:12   0:13 io.discovery.0
iobroker   235  0.1  3.3 174356 63888 ?        Sl   18:12   0:13 io.backitup.0
iobroker   265  0.2  3.4 179412 66192 ?        Sl   18:12   0:15 io.iot.0
iobroker   272  0.1  2.8 168568 54156 ?        Sl   18:12   0:12 io.jarvis.0
iobroker   295  0.2  3.4 181224 65860 ?        Sl   18:12   0:15 io.info.0
iobroker   384  0.2  3.2 178344 61652 ?        Sl   18:12   0:16 io.cloud.0
iobroker   619  0.6  2.9 169508 56136 ?        Sl   18:12   0:48 io.net-tools.0
iobroker   634  0.4  3.7 187824 72068 ?        Sl   18:12   0:29 io.vw-connect.0
iobroker  7168  0.8  2.9 167556 55996 ?        Sl   20:06   0:03 io.web.0
root@22b3c96e22ae:/opt/iobroker#

[Thomas Braun]

@mick70 sagte in Nach Update von WEB 3.4.16 kein VIS mehr:

Nachdem jetzt alle Adapter außer VIS rennen, fänd' ichs halt ... naja, anstrengend

Backup ziehen, frisch nativ neuinstallieren, Backup wieder einspielen.

[apollon77]

@mick70 mach mal ein „iob upload all“. Ist der Fehler dann weg?

[mick70]

@thomas-braun
So, Backup gemacht, docker abgeschaltet, IOB nativ installiert, lief. Versucht, das Backup einzuspielen - über 20 Minuten keine Reaktion mehr. Hab IOB dann gestoppt, gefixt (geht ja jetzt) und neu gestartet, leider passiert da jetzt aber gar nix mehr, die GUI ist nicht mehr erreichbar.

Genug kaputt gemacht für heut, vllt mach ich morgen weiter oder fang halt wieder ganz bei null an. :confused:

[Thomas Braun]

@mick70 sagte in Nach Update von WEB 3.4.16 kein VIS mehr:

Versucht, das Backup einzuspielen - über 20 Minuten keine Reaktion mehr.

Das kann ggf. deutlich länger dauern. In

iobroker logs --watch

kann man den Fortgang sehen.

[mick70]

@thomas-braun
Oh unheilige Ungeduld... :grimacing:
Dann halt morgen nochmal ab "restore" :grinning:

[mick70]

Habs nochmal das Restore von vorn probiert. Im Log endet die Installation leider an dieser Stelle ohne weitere Änderung:

2022-02-08 21:37:18.615  - info: host.22b3c96e22ae 15 instances found
2022-02-08 21:37:18.626  - warn: host.22b3c96e22ae does not start any instances on this host

Ich lass mal laufen, aber vmtl muss ich morgen dann doch wieder bei null anfangen.

[Thomas Braun]

@mick70 sagte in Nach Update von WEB 3.4.16 kein VIS mehr:

host.22b3c96e22ae

Das ist/war der Container?
Der hostname muss geändert werden.

[mick70]

@thomas-braun

Hehe, nach Änderung des Host-Namens wäre das Restore wohl doch noch aus dem alten Backup möglich gewesen.

Ich habe nun trotzdem lieber alles neu nativ aufgesetzt, ohne Rückstände von Docker, Portainer etc. und natürlich auch mit nativem Pi-Hole. Was soll ich sagen, auch VIS läuft jetzt out of the box (socketio 4.1.0, web 3.4.16).

Der richtige Tipp war für mich damit: Weg mit Docker. Ist es clever, dafür ein +1 zu geben? Das Problem in meiner Installation lief ja irgendwie am Thread-Thema vorbei...

[Ben1983]

Hallo,

ist eine neuere Version als die 3.4.16 angedacht? Die lief ja bei vielen nicht, oder hat sich was geändert?

[apollon77]

@ben1983 Wie in andren Foren Threads geschrieben ist die 4.1.x von Web wieder "gut"

[Ben1983]

@apollon77 ok, also kann die geupdatet werden?

Edit: Ach die ist bestimmt noch beta. oder?

[Thomas Braun]

@ben1983

web
github:	4.1.4
latest:	4.1.4 for 0 days
stable:	3.4.16 for 91 days

[apollon77]

@ben1983 sagte in Nach Update von WEB 3.4.16 kein VIS mehr:

Edit: Ach die ist bestimmt noch beta. oder?

exakt ist sie

[luckytgx]

Hallo zusammen,

ich bin am verzweifeln. Meine VIS hat auch das NO CONNECTION Problem und selbst nach stundenlanger Recherche konnte ich die Sache nicht lösen.

Überall liest man den Tipp auf die socket.io Version 3.1.5 zu wechseln. Ich habs mit NPM probiert, aber es bleibt immer auf 4.2.0.

Wobei mir ein NPM list socket.io das hier ausgibt:
iobroker.inst@2.0.3 C:\Program Files\iobroker\SmartHome0922

+-- iobroker.jarvis@3.0.13
| `-- socket.io@4.5.2
+-- iobroker.socketio@4.2.0
| `-- socket.io@2.5.0
+-- iobroker.terminal@0.2.6
| `-- socket.io@4.5.2
+-- iobroker.web@4.3.0
| `-- iobroker.socketio@4.2.0
|   `-- socket.io@2.5.0
`-- socket.io@4.5.2

IOBroker bietet mir im Expert mode nur folgende socket.io Versionen an:

Wenn ich mit NPM versuche auf socket.IO@3.1.5 zu downgraden, findet er die Version nicht: No matching version found for socket.io@3.1.5.

Aktuell habe ich folgende Versionen von VIS, web und socket.io:
iobroker.web@4.3.0
iobroker.vis@1.4.15

Lt. Admin-Oberfläche im iobroker habe ich die socket.io Version 4.2.0 installiert:

Habt ihr einen Tipp für mich wie ich es schaffe auf die socket.io Version 3.1.5 downzugraden?
Gibts inzwischen eine andere Lösung für das Problem, auf die ich nur noch nicht gestoßen bin?

Danke & LG,
Lucky

[DJMarc75]

@luckytgx sagte in Nach Update von WEB 3.4.16 kein VIS mehr:

Überall liest man den Tipp auf die socket.io Version 3.1.5 zu wechseln.

??? Welche alten Threads liest Du denn ???

@luckytgx sagte in Nach Update von WEB 3.4.16 kein VIS mehr:

Ich habs mit NPM probiert

bitte nicht !

Suchfunktion hier bitte benutzen Stichwort "Verbindungsfehler"

hier ein Lösungsbeispiel:

https://forum.iobroker.net/topic/55990/erledigt-keine-anzeige-der-projekte-in-visedit/3