Der neue Monatsrückblick für Mai und Juni 2026 ist online!

[Aubergino]

Hallo wendy2702, das sind die Hinweise, die man braucht! Nee, in der Instanz war nur "Info" eingestellt. Danke! Jetzt kommt:

shelly.0
	2026-08-11 18:48:38.483	debug	[firmwareNotify] Starting firmware check on every device
shelly.0
	2026-08-11 18:48:28.480	debug	[MQTT Server] Started listener on 192.168.178.7:1882
shelly.0
	2026-08-11 18:48:28.470	info	Starting in MQTT mode. Listening on 192.168.178.7:1882 (QoS 0)
shelly.0
	2026-08-11 18:48:28.413	info	starting. Version 10.6.1 in D:/ioBroker/node_modules/iobroker.shelly, node: v22.23.1, js-controller: 7.1.2
shelly.0
	2026-08-11 18:48:28.295	debug	Plugin sentry Do not initialize Plugin (enabled=false)
host.PC-Knut
	2026-08-11 18:48:05.603	info	instance system.adapter.shelly.0 in version "10.6.1" started with pid 16232 

Dabei bleibt es, mehr passiert nicht.

[mcm1957]

Deine Netzwerkeinstellung ist falsch. Der Adapter lauscht nur auf 192.168.178.7 - das ist die IP des hosts und kein Netzwerk.

Stell das mal so ein:

[Peter V.]

Sind deine Shelly Passwort geschützt?
Falls nein, in den Instanzeinstellungen "Allgemeine Einstellungen" die Felder löschen.

[mcm1957]

@Peter-V. sagte:

Sind deine Shelly Passwort geschützt?
Falls nein, in den Instanzeinstellungen "Allgemeine Einstellungen" die Felder löschen.

Danke für die Anregung.
Aber das ist definitiv nicht das Problem. Da würden logs kommen. Lt. Log erreicht der Shelly den Adapter nicht mal. Wie oben geschrieben ist die Netzwerkeinstellung prüfenswert.

[Peter V.]

Kann sein, aber bei mir (ok, PVE-LXC-Installation) steht auch die IP des IOBroker Hosts drin. Alles ist möglich.
Ich täte mal einen Ping auf den Shelly empfehlen, ob dieser im Netzwerk antwortet.

[Aubergino]

Danke an die Mitdenkenden,
DIe Einstellung ohne IOBroker-Host-Festlegung hatte ich vorher schon probiert (jetzt nochmal), aber das ändert nichts.
Der Shelly ist Passwortgeschützt, dazu hatte ich oben auch mal gefragt, ob es normal ist, dass das Passwortfeld in den Shelly-Einstellungen nach Eingabe und Speichern beim nächsten Aufruf der Einstellungen leer ist, und ein 4-ziffriges Passwort für MQTT zu kurz ist? Passwort in beiden Shelly-Einstellunge und im Modbus-Adapter sind übereinstimmend eingegeben.
Nach dem ich jetzt wieder auf "Listen on all IP's zurückgeändert und neu gestartet hatte, stand im Protokoll:

shelly.0
	2026-08-11 22:33:12.073	debug	[firmwareNotify] Starting firmware check on every device
shelly.0
	2026-08-11 22:33:02.081	debug	[MQTT Server] Started listener on 0.0.0.0:1882
shelly.0
	2026-08-11 22:33:02.071	info	Starting in MQTT mode. Listening on 0.0.0.0:1882 (QoS 0)
shelly.0
	2026-08-11 22:33:02.014	info	starting. Version 10.6.1 in D:/ioBroker/node_modules/iobroker.shelly, node: v22.23.1, js-controller: 7.1.2
shelly.0
	2026-08-11 22:33:01.916	debug	Plugin sentry Do not initialize Plugin (enabled=false)
shelly.0
	2026-08-11 22:33:01.897	debug	States connected to redis: 127.0.0.1:9000
shelly.0
	2026-08-11 22:33:01.890	debug	States create User PubSub Client
shelly.0
	2026-08-11 22:33:01.889	debug	States create System PubSub Client
shelly.0
	2026-08-11 22:33:01.884	debug	Redis States: Use Redis connection: 127.0.0.1:9000
shelly.0
	2026-08-11 22:33:01.874	debug	Objects connected to redis: 127.0.0.1:9001
shelly.0
	2026-08-11 22:33:01.856	debug	Objects client initialize lua scripts
shelly.0
	2026-08-11 22:33:01.841	debug	Objects create User PubSub Client
shelly.0
	2026-08-11 22:33:01.841	debug	Objects create System PubSub Client
shelly.0
	2026-08-11 22:33:01.839	debug	Objects client ready ... initialize now
shelly.0
	2026-08-11 22:33:01.822	debug	Redis Objects: Use Redis connection: 127.0.0.1:9001
host.PC-Knut
	2026-08-11 22:32:59.815	info	instance system.adapter.shelly.0 in version "10.6.1" started with pid 13832
host.PC-Knut
	2026-08-11 22:32:59.500	info	"system.adapter.shelly.0" enabled 

Mir fällt darin nur auf, dass bei der IP 127.0.0.1 (eigener Rechner, ja?) immer Port 9000 oder 9001 dahinter steht. Der Shelly-Port ist ja 1882. Kann da der Hase im Pfeffer hoppeln? Ich weiß nicht, was redis bedeutet..
Für heute ist erst mal Feierabend.

[Homoran]

@Aubergino sagte:

Port 9000 oder 9001 dahinter steht. Der Shelly-Port ist ja 1882. Kann da der Hase im Pfeffer hoppeln? Ich weiß nicht, was redis bedeutet..

Das sind die internen Datenbanken für Objects und States

[Thomas Braun]

@Aubergino sagte:

js-controller: 7.1.2

Installation auf Stand bringen, Rest auch.

[Samson71]

@Aubergino sagte:
Der Shelly ist Passwortgeschützt,

Stellt sich die Frage warum? Ist eher eine zusätzliche potentielle Fehlerquelle. Zumindest bis es läuft würde ich das weglassen. Ist Dein Netzwerk so gefährdet oder unsicher, dass das sein muss? Gibt es "Spielkinder" im Netzwerk, die davon abgehalten werden müssen/sollen darauf zugreifen zu können?

[Aubergino]

Danke für die weiteren Hinweise,
@thomas-braun.. IOBroker ist noch keine 3 Wochen installiert, der Adapter zuletzt vorgestern? Den Shelly habe ich nun auch noch updatet, der war tatsächlich auf Stand 1.7... von 2023. Klappt trotzdem nicht.
@Samson71.. Naja, auch WLANs können gehackt werden, oder gehackte shellies Zugang in mein WLAN verschaffen? Soll aber hier nicht das Thema sein - ich hab's probiert, auch da klappt es nicht.
@peter-v. ..Ich pinge alle Netzwerkgeräte regelmäßig an. Beim Shelly hätte ich ja aber auch die Benutzeroberfläche des Shelly nicht erreicht, wenn es nicht im Netzwerk wäre.

[Aubergino]

Ich frage mich aber, warum das Debug-Protokoll immer mit diesem "Firmware-Check aller Geräte" stehen bleibt.

[Thomas Braun]

@Aubergino

js-controller: 7.1.2
aber 7.2.2 ist das aktuelle stabile Release:

js-controller
latest:	7.2.2 for 56 days
stable:	7.2.2 for 56 days

[Aubergino]

ok, das hast Du im Protokoll auslesen können. Woher kommt dieser js-controller? Aus dem Shelly-Adapter? Aus der IOBroker-Installation? Anders gefragt - wie aktualisiere ich den? Pardon, aber wir sind im Einsteiger-Forum...

[Thomas Braun]

@Aubergino

Das ist die zentrale Komponente deines ioBrokers.
Aber zu Windows kann ich dir nichts sagen, hier läuft das natürlich alles unter Linux.
Keine Ahnung, ob die Vorgehensweisen da gleich wären.

[Aubergino]

Wieso "natürlich"? Aber darum soll es hier nicht gehen.. Dass die zentrale Komponente des ioBrokers keine drei Wochen nach der Installation outdated ist und sehr verbreitete Adapter deshalb nicht mehr funktioniern, scheint kaum vorstellbar bzw. wäre ein Argument, den ioBroker als IoT-Zentrale nicht zu verwenden. Was sehr schade wäre... Wie auch immer:
Ich finde leider nirgendwo einen Menupunkt zum updaten des ioBrokers. Wo ist denn der versteckt?

[Thomas Braun]

@Aubergino sagte:

Wieso "natürlich"? Aber darum soll es hier nicht gehen..

Weil mit Abstand die meisten Installationen auf einer Linux-Basis laufen und es deswegen auch für dieses Setup die meiste Expertise und Erfahrungswerte gibt.

Dass die zentrale Komponente des ioBrokers keine drei Wochen nach der Installation outdated ist und sehr verbreitete Adapter deshalb nicht mehr funktioniern, scheint kaum vorstellbar bzw. wäre ein Argument, den ioBroker als IoT-Zentrale nicht zu verwenden.

Der ioBroker bekommt beständig Updates, ist quasi ein 'rolling release'. Kann natürlich sein, dass auch für ein vor drei Wochen installiertes System natürlich bereits Updates anstehen. 'Never tatsch irgendwas' ist jedenfalls kein sinnvoller Ansatz, egal welches OS verwendet wird.

https://forum.iobroker.net/topic/84818/wichtiges-update-für-controller-7.2.2-im-stable

Soweit ich weiß wird ein Update des js-controllers unter Windows mit dem Installer vorgenommen. Aber ob der noch richtig gepflegt wird und ob da irgendwas angepasst werden muss... K.A., da das hier alles sehr gut unter Linux läuft. Mit entsprechenden Update-Routinen.

[Aubergino]

Du hast recht, Update via Installer. Läuft auch los nach Beenden der IOBroker-Dienste, meldet aber nach einiger Zeit, dass das Update gescheitert ist. Verweist auf den Log, nachdem "Updat Done" sei, aber statt "Traget" (soll wohl "Target" heißen) JS-Controller 7.2.2. steht nach "installed" doch 7.1.2. Also stimmt wohl eher "gescheitert" als "done".

----------------------------------------------------------------------------------------------------
Npm prefix path exists: C:\Users\Knut\AppData\Roaming\npm ---> OK
----------------------------------------------------------------------------------------------------

Executing:
----------------------------------------------------------------------------------------------------
@echo off
SET PATH=C:\Program Files\nodejs;%PATH:&=^&%
"C:\Program Files\nodejs\node.exe" "D:\ioBroker\node_modules\iobroker.js-controller/iobroker.js" upgrade self
----------------------------------------------------------------------------------------------------
Update js-controller from @7.1.2 to @7.2.2
Stopped Objects DB
Stopped States DB
NPM version: 12.0.2
Installing iobroker.js-controller@7.2.2... (System call)
----------------------------------------------------------------------------------------------------
JS-Controller Update done.
Verification: Traget JS-Controller: 7.2.2, installed: 7.1.2
----------------------------------------------------------------------------------------------------

Meine Frustrationstoleranz ist nach so vielen Stunden vergeblicher Bemühungen mit diversen Adaptern und Instanzen gerade überschritten. Ich stelle das ganze erst mal für eine Weile hintan. Schade, war sehr vielversprechend!

[Thomas Braun]

@Aubergino sagte:

NPM version: 12.0.2

Könnte mit der Version zusammenhängen. Bei aktuellen npm-Versionen werden post-installation Skripte nicht mehr automatisch ausgeführt. Weswegen die vorgesehene nodejs@22 auch mit npm@10.9.8 daher kommt, da gibt es diese Einschränkung nämlich noch nicht.

[Aubergino]

Da hättest Du mir jetzt auch den Fahrplan der Transsibirischen Eisenbahn vorlesen können...

[Thomas Braun]

@Aubergino

Nee, die musste selber lesen:

https://www.transsibirische-eisenbahn.de/detailfahrplaene/