Monatsrückblick Januar/Februar 2026 ist online!

[Asgothian]

@rockflopp sagte in Shelly Adapter stürzt ab ENETUNREACH:

Ich frage mich:
Wie kann man das Setup Fehlertoleranter gestalten, so dass er erstens bei nicht Erreichbarkeit eines Devices nicht abstürzt und wenn der Adapter neu startet dann auch entsprechend lange auf die Geräte wieder wartet

Wie macht man das ?

• Issue auf GitHub aufmachen (am Adapter Repository)
• Aussagekräftige Fehlermeldung Eintragen
• Entsprechenden Kontext mitliefern (Adapterversionen Node Version, etc.)
• Entsprechende Log einträge mit liefern (Und das nicht als Screenshot)

A.

[rockflopp]

@asgothian

Nach allen updates besteht der Fehler weiterhin. Noch eine Idee oder nun den von dir beschriebenen Weg beschreiten?

2022-05-24 06:32:30.727 - error: shelly.0 (28522) uncaught exception: send ENETUNREACH 192.168.0.24:5683
2022-05-24 06:32:30.740 - error: shelly.0 (28522) Error: send ENETUNREACH 192.168.0.24:5683
at doSend (dgram.js:714:16)
at defaultTriggerAsyncIdScope (internal/async_hooks.js:452:18)
at afterDns (dgram.js:660:5)
at processTicksAndRejections (internal/process/task_queues.js:83:21)
2022-05-24 06:32:30.741 - error: shelly.0 (28522) Exception-Code: ENETUNREACH: send ENETUNREACH 192.168.0.24:5683
2022-05-24 06:32:30.818 - info: shelly.0 (28522) Closing Adapter
2022-05-24 06:32:30.819 - info: shelly.0 (28522) terminating
2022-05-24 06:32:30.822 - warn: shelly.0 (28522) Terminated (UNCAUGHT_EXCEPTION): Without reason
2022-05-24 06:32:30.988 - error: host.iobroker-pi Caught by controller[0]: Error: send ENETUNREACH 192.168.0.24:5683
2022-05-24 06:32:30.996 - error: host.iobroker-pi Caught by controller[0]: at doSend (dgram.js:714:16)
2022-05-24 06:32:30.996 - error: host.iobroker-pi Caught by controller[0]: at defaultTriggerAsyncIdScope (internal/async_hooks.js:452:18)
2022-05-24 06:32:30.996 - error: host.iobroker-pi Caught by controller[0]: at afterDns (dgram.js:660:5)
2022-05-24 06:32:30.997 - error: host.iobroker-pi Caught by controller[0]: at processTicksAndRejections (internal/process/task_queues.js:83:21)
2022-05-24 06:32:30.998 - error: host.iobroker-pi instance system.adapter.shelly.0 terminated with code 1 (JS_CONTROLLER_STOPPED)
2022-05-24 06:32:30.998 - info: host.iobroker-pi Restart adapter system.adapter.shelly.0 because enabled
2022-05-24 06:32:32.158 - info: host.iobroker-pi instance system.adapter.shelly.0 started with pid 8151
2022-05-24 06:32:34.562 - info: shelly.0 (8151) starting. Version 5.3.2 in /opt/iobroker/node_modules/iobroker.shelly, node: v14.19.2, js-controller: 4.0.23
2022-05-24 06:32:35.130 - info: shelly.0 (8151) Starting in CoAP mode.
2022-05-24 06:32:35.207 - info: shelly.0 (8151) [CoAP] Listening for packets in the network

Beste Grüße

[rockflopp]

Eine Suche bei den Github Issues gab es einen Lösungsvorschlag bei dem die maximale Stromentnahme hochgesetzt wird, das werde ich jetzt mal probieren.
https://github.com/iobroker-community-adapters/ioBroker.shelly/issues/65

[Thomas Braun]

@rockflopp

Betreibst du denn einen WLAN-Stick an einem der USB-Ports? Der iobroker-Server sollte eigentlich immer per LAN-Kabel betrieben werden.

[rockflopp]

@thomas-braun nein per LAN plus Zigbee Stick

[Thomas Braun]

@rockflopp
Im Issue ging es um WLAN-Sticks, die zu wenig Saft über USB bekamen und dann Aussetzer im Netz verursacht haben.

[mbw]

Hi zusammen,

gibt es hier etwas Neues? Ich habe auch das Problem mit dem abstürzenden Shelly-Adapter, alle paar Stunden wird bei mir nach dem gleichen Fehler die Instanz neue gestartet.

Danke!

[da_Woody]

@mbw was soll es neues geben? am shelly adapter liegts sicher nicht. seit 3 jahren COAP instanz am laufen, seit monaten eine 2. MQTT, kein einziger absturz trotz jeder beta.
ich tipp da eher auf euer netzwerk.

[mbw]

@da_woody ja, das kann ja sein, aber trotzdem wird ja hier eine Exception nicht behandelt weswegen der Adapter dann abstürzt.

[da_Woody]

@mbw das mein ich ja, der adapter stürzt nich einfach ab. da muss was anderes sein im netzwerk.
hab da auch schon einiges drüber getippt.
igmp snooping... als tip
waren zwar keine abstürze, aber es kamen keine daten mehr.

[Homoran]

@mbw sagte in Shelly Adapter stürzt ab ENETUNREACH:

alle paar Stunden wird bei mir nach dem gleichen Fehler die Instanz neue gestartet.

wirklich identisch?
zeigen!

@mbw sagte in Shelly Adapter stürzt ab ENETUNREACH:

trotzdem wird ja hier eine Exception nicht behandelt weswegen der Adapter dann abstürzt.

ist das so?

[rockflopp]

Hallo @da_woody, der Fehler tritt bei mir leider auch weiterhin mehr weniger regelmäßig auf. Sollen wir mal einen Bug Report direkt beim Adapter aufmachen? Oder konntest du inzwischen die Ursache lokalisieren?
Habe 50 WLAN IOT Geräte mit fixer IP und einen zusätzlichen WLAN Accesspoint.

Dass ein Shelly mal nicht erreichbar ist sollte nicht zum Absturz des Adapters führen. Zumindest suggeriert das ja die Fehlermeldung.

2023-03-21 06:05:03.095 - error: shelly.0 (866) uncaught exception: send ENETUNREACH 192.168.0.66:5683
2023-03-21 06:05:03.101 - error: shelly.0 (866) Error: send ENETUNREACH 192.168.0.66:5683
at doSend (dgram.js:714:16)
at defaultTriggerAsyncIdScope (internal/async_hooks.js:452:18)
at afterDns (dgram.js:660:5)
at processTicksAndRejections (internal/process/task_queues.js:83:21)
2023-03-21 06:05:03.102 - error: shelly.0 (866) Exception-Code: ENETUNREACH: send ENETUNREACH 192.168.0.66:5683
2023-03-21 06:05:03.130 - info: shelly.0 (866) terminating
2023-03-21 06:05:03.132 - warn: shelly.0 (866) Terminated (UNCAUGHT_EXCEPTION): Without reason
2023-03-21 06:05:03.266 - error: host.iobroker-pi Caught by controller[0]: Error: send ENETUNREACH 192.168.0.66:5683
2023-03-21 06:05:03.273 - error: host.iobroker-pi Caught by controller[0]: at doSend (dgram.js:714:16)
2023-03-21 06:05:03.274 - error: host.iobroker-pi Caught by controller[0]: at defaultTriggerAsyncIdScope (internal/async_hooks.js:452:18)
2023-03-21 06:05:03.274 - error: host.iobroker-pi Caught by controller[0]: at afterDns (dgram.js:660:5)
2023-03-21 06:05:03.275 - error: host.iobroker-pi Caught by controller[0]: at processTicksAndRejections (internal/process/task_queues.js:83:21)
2023-03-21 06:05:03.276 - error: host.iobroker-pi instance system.adapter.shelly.0 terminated with code 1 (JS_CONTROLLER_STOPPED)
2023-03-21 06:05:03.276 - info: host.iobroker-pi Restart adapter system.adapter.shelly.0 because enabled
2023-03-21 06:05:04.431 - info: host.iobroker-pi instance system.adapter.shelly.0 started with pid 26157
2023-03-21 06:05:06.682 - info: shelly.0 (26157) starting. Version 6.3.1 in /opt/iobroker/node_modules/iobroker.shelly, node: v14.19.2, js-controller: 4.0.24
2023-03-21 06:05:07.363 - info: shelly.0 (26157) [firmwareUpdate] Auto-Update enabled - devices will be updated automatically
2023-03-21 06:05:07.365 - info: shelly.0 (26157) Starting in CoAP mode. Listening on 0.0.0.0:5683
2023-03-21 06:05:07.455 - info: shelly.0 (26157) [CoAP Server] Listening for packets in the network
[s=]
 
[/s]

[da_Woody]

@rockflopp ich bin sicher kein profi, arbeite aber seit 2019 fast ausschließlich mit shelly.
selbst bei problemen ist mir der shelly adapter nie abgestüzt. sind halt teilweise keine daten in die objekte gekommen.
siehe postings meinereiner über IGMP und mcast und unicast.

edith: zuwu bugreport? IMHO gibts da keine bugs, sondern probs in euren netzwerken.
@haus-automatisierung hat da alles soweit umgebaut, daß das alles funktioniert. tuts ja auch bei bei so gut wie allen usern.
keine ahnung, wieviele den adapter mit ioB verwenden. seltsam halt, wenn ein paar leute probleme haben.

[rockflopp]

@da_woody kannst du mir einen Tipp geben nach was ich in meinem Netzwerk Ausschau halten soll? Die iOT Geräte gehen entweder direkt per wlan auf den Vodafone Router oder indirekt über einen Access Point der mit Lan mit dem Router verbunden ist. Die Einstellmöglichkeiten beim Vodafone Router sind begrenzt von daher bin ich für nächste Schritte bei der Problembehebung dankbar. Der Adapter stürzt nun wieder häufiger ab… :-(

[da_Woody]

@rockflopp ist mit den "kastrierten" vodafone dingens schwer. ich kenn die dinger nicht, hab aber immer wieder über probleme gelesen.
darum ist bei mir die fritzbox rausgeflogen. da konnte ich, laut support beim provider, den routerteil nicht deaktivieren.
angeblich war das aus rechtlichen gründen für österreich von avm nicht freigegeben.
ich hab aber ein synology netzwerk mit router und einigen APs dahinter. 2 router hintereinander vertragen sich nicht.
hab dann vom provider eine andere box bekommen von technicolor, dort konnte ich umschalten auf reinen modembetrieb.