Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[rockflopp]

Hallo zusammen,

folgendes Fehlerbild. Ca alle 2-5 Tage verabschiedet sich der Shelly Adapter. Der geloggte Grund ist ENETUNREACH eines der Shelly Devices. Laut Log wird der Adapter auch neu gestartet aber es ist dann kein Shelly erreichbar (es finden sich danach keine Device connected Meldungen im Log) erst wenn man den Adapter manuell neu startet (meistens am nächsten Morgen) funktioniert es wieder. Im Log sieht man auch dass andere Adapter ihre devices verlieren. Scheint es ein Netzwerkausfall (Router / Raspberry) zu sein?

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 finde ich die Ursache des Problems heraus (Netzwerk weg oder Problem mit Raspi oder irgendwas anderes)

Danke schon mal für eure Unterstützung

[arteck]

@rockflopp update des js-contreoller bitte..wir sind auf 4.x

[rockflopp]

Done... jetzt dauert es tatsächlich einiges länger aber dennoch:

ENETUNREACH, Absturz, Restart, Keine Shellys werden gefunden, Nur manueller Restart des Shelly Adapters hilft

[Thomas Braun]

@rockflopp

Bring dein nodejs auf Version 14.

[rockflopp]

@thomas-braun
done, nun Problem mit BLE Adapter welcher nicht mehr startet :-(

[Thomas Braun]

@rockflopp

Lösung steht im Screenshot.
Da ich den nicht kopieren kann: Schau selber.

[rockflopp]

@thomas-braun
so wirklich voran geht es nicht, jedesmal ne andere Fehlermeldung aber das Ergebnis ist immer noch das gleiche. Netzwerkfehler führt zu Absturz des Shelly Adapters und nur ein restart hilft....

[Thomas Braun]

@rockflopp

Screenshots kann ich nicht lesen.

[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]