Shelly Debugging leicht gemacht – Ausfälle erkennen, analysieren und vermeiden

Aus Laub-Home Wiki

Shelly Geräte sind eine beliebte Lösung zur Heimautomatisierung, doch viele Nutzer kennen das Problem: Geräte sind plötzlich nicht mehr erreichbar, reagieren träge oder stürzen ohne erkennbaren Grund ab. Diese Anleitung hilft dir dabei, genau diese Probleme systematisch zu analysieren und zu beheben.

Du erfährst, wie du mit einfachen Mitteln und hilfreichen Skripten ein effektives Monitoring einrichtest, Debug-Informationen sammelst und gezielt Fehlerquellen identifizierst.

Warum stürzen Shelly Geräte ab oder sind nicht erreichbar?

Shelly Geräte sind kompakte, leistungsfähige WLAN-fähige Smart-Home-Komponenten, die jedoch unter bestimmten Bedingungen zu Ausfällen oder Nichterreichbarkeit neigen. Im Folgenden werden die häufigsten Ursachen und deren Symptome erläutert:

WLAN-Probleme

Ein häufiger Grund für Verbindungsabbrüche ist eine instabile WLAN-Verbindung. Besonders bei schlechter Signalstärke, Interferenzen (z. B. durch andere Netzwerke oder Mikrowellen) oder überlasteten Routern kann es zu Paketverlusten und Verbindungsabbrüchen kommen. Shelly Geräte benötigen eine stabile Verbindung, um dauerhaft erreichbar zu bleiben.

Lösungsansätze:

  • WLAN-Kanal wechseln oder optimieren (z. B. durch Nutzung von 2,4 GHz Band mit möglichst wenig Überlagerung)
  • Netzwerk und WLAN Konfiguration auf Shelly Devices optimieren
    • eigenes IoT Netzwerk mit eigener SSID wenn möglich
      • 2,4 GHz Band, Kanal statisch festlegen (1, 6, 11),
      • setzt die TX Power auf low (Antennen Sendeleistung niedrig)
      • aktivieren von mDNS & mDNS Proxy
      • deaktivieren von Roaming
      • deaktivieren von IGMP Snooping
      • deaktivieren von UAPSD (Power Savings)
      • deaktivieren von Multicast Enhancement
  • zusätzliche Access Points, WLan Repeater oder Mesh-Systeme gezielt platzieren
  • Antenne richtig ausrichten bzw. abschirmen (https://community.shelly.cloud/topic/3387-shelly-relais-installation-position-in-wall/)
  • Bei schlechtem WLan Empfang feste IP Adresse vergeben.
  • eventuell bei schlechter WLan Verbindung Kommunikation via MQTT anstelle von Webschnittstellen (OpenHAB Shelly IoT Devices mittels MQTT einbinden)

Überhitzung

In engen Installationsumgebungen oder bei dauerhaft hoher Schaltlast kann sich ein Shelly stark erhitzen. Übertemperaturschutz greift dann häufig zu spät oder führt zum plötzlichen Reboot.

Lösungsansätze:

  • Verwendung großer Einbaudosen
  • Verkabelung: Kabelsalat vermeiden
  • Shelly ECO Mode aktivieren
  • Lüftung oder Entwärmung verbessern
  • Einsatzort kritisch hinterfragen

Firmware-Probleme

Fehlerhafte oder veraltete Firmware-Versionen können Instabilitäten verursachen. Besonders nach automatischen Updates treten mitunter unerwartete Nebenwirkungen auf.

Lösungsansätze:

Netzwerkkonfiguration & DHCP

Unklare oder fehlerhafte IP-Zuweisung (z. B. bei instabilen DHCP-Servern oder IP-Adresskonflikten) kann dazu führen, dass Shelly Geräte im Netz nicht mehr erreichbar sind.

Lösungsansätze:

  • Feste IP-Adressen vergeben
  • Router/DHCP-Logs prüfen
  • DNS-Konfiguration überprüfen

Werkzeuge zur Überwachung und Fehleranalyse

Folgende Skripte und Werkzeuge haben sich zur Überwachung und Fehleranalyse von Shelly-Geräten bewährt:

shelly-status-check.py

  • Funktion: Prüft die Erreichbarkeit und den Status mehrerer Shelly-Geräte über deren REST-API.
  • Einsatz: Zur regelmäßigen Überwachung, ob Geräte online sind und korrekt antworten.
  • Ausgabe: IP-Adresse, Erreichbarkeit, installierte Scripte, Eco Mode, Bluetooth und MQTT Status, etc.

shelly-check.sh

  • Funktion: Einfaches Shell-Skript zur Verfügbarkeitsprüfung per HTTP (ping-artig)
  • Einsatz: Ideal für cronjob-gestützte Basisüberwachung, auch in minimalistischen Umgebungen ohne Python, da einfaches BASH Script.

shelly-debug-setter.py

  • Funktion: Aktiviert den Debug-Modus bei Shelly-Geräten über die HTTP API.
  • Einsatz: Zur gezielten Fehleranalyse bei instabilen Geräten oder zur Vorbereitung von Log-Erfassung.

shelly-mqtt-config.py

  • Funktion: Prüft, ob die MQTT-Konfiguration korrekt gesetzt ist und das Gerät erfolgreich mit dem Broker verbunden ist.
  • Einsatz: Zur Validierung der Kommunikation zwischen Shelly und einem zentralen MQTT-Broker (z. B. bei Home Assistant Setups).

Syslog-Server Docker Stack

Vorgehen zur Überwachung und Fehleranalyse

Wie geht man nun am besten vor, wenn man wissen will ob alles rund läuft, und wenn nein, woran es liegen könnte. Ich nutze dafür alle oben stehenden Werkzeuge, die in eigenen Kapitel jeweils nochmals genau beschrieben sind. Das Analysevorgehen sieht wie folgt aus:

  1. Monitoring: Regelmäßige Prüfung ob alle Shelly Devices erreichbar sind, oder ob es Geräte gibt die ab und an nicht erreichbar sind. Dafür richte ich das Skript shelly-check.sh ein, damit es alle 5 Minuten alle meine Shelly Devices auf Verfügbarkeit prüft und mir im Fehlerfall einfach eine E-Mail schickt. Ich monitore die Häufigkeit dann einfach mit einer art Strich Liste (ShellyDeviceXYZ IIIII) So kann ich eine gewisse Regelmäßigkeit erkennen und man identifiziert schnell welche Shellies Probleme haben.
  2. Problemanalyse: Um nun herauszufinden, was das Problem der nicht Erreichbarkeit des Shelly Devices ist, braucht es einen Syslog-Server, an den alle Shellies ihre Debug Messages schicken. Die Konfiguration aller Shellies kann mittels Skript shelly-debug-setter.py in einem Rutsch geschehen, oder aber auch via Webinterface unter Settings --> Debug --> UDP Debug manuell geschehen. Loggen nun alle Devices dort hin, kann man sich in Ruhe die Logs anschauen. Im falle meines Beispiels, ganz bequem via Webinterface. So kann man auf das Device zum Beispiel Filtern und sich dann die Logzeilen zeitlich zum Ausfall anzeigen lassen. Man kann auch nach ERROR oder WARNING filtern und so sehen, ob die Geräte Fehler melden, die es ggf. zu beheben gilt.
  3. Statusabfrage: Um sich einen Überblick über die wichtigsten Funktionen der im Einsatz befindliche Shelly Devices zu machen, nutze ich dann das shelly-status-check.py. Hier interessiert mich im Normalfall als aller erstes, welche Geräte haben schlechten WIFI Empfang (Option: --sort wifi). Meiner Erfahrung nach ist alles unter 80 RSSI OK. Alles darüber sollte man beobachten. Ich handhabe hier zum Beispiel, das ich Geräten mit schlechtem Empfang den Shelly ECO Mode auf jeden Fall deaktiviere. Ein anderer Punkt, der interessant ist und auf ein stabiles Shelly Ökosystem hinweist ist die Uptime der Shellies (Option: --sort uptime). Wenn hier Geräte eine sehr kurze Uptime haben, und ihr das Gerät nicht selbstständig neugestartet habt, kein Stromausfall war, deutet es auf einen Absturz hin. Diesen kann man dann zeitlich wieder im Syslog Webinterface überprüfen.

Tips für ein stabiles Shelly Smart-Home

  • Sorgt überall für guten WLan Empfang, das ist wirklich das Wichtigste!
  • Aktuelle Firmware auf allen Shellies installieren, es gab bei älteren Firmware Versionen regelmäßige Abstürze mit CoreDumps bei mir.
  • Habt ihr ein Gerät identifiziert, welches schlechten Empfang hat und ihr es nicht vermeiden könnt:
    • Stellt in den WLAN Einstellungen ein das Roaming erst zum Beispiel bei -85 RSSI geschehen soll, ggf. das Intervall von 60 auf 180 oder gar 300 Sekunden erhöhen. Das Device würde sonst viel zu oft nach einem besseren Accesspoint suchen.
    • Schaut ob die Nutzung zum Beispiel über MQTT besser funktioniert als über die WEB API
    • Es hilft auch manchmal die Position des Shelly in der Dose ein wenig zu ändern, oder den Shelly Plug zu andersherum einzustecken
  • ECO Modus deaktivieren
    • habe ich zum Beispiel auf allen Geräten die häufiger nicht erreichbar waren
    • auf allen Geräten auf denen ich Scripte laufen habe

All das hat bei mir dafür gesorgt das meine Shelly Infrastruktur aus 100+ Geräten stabil läuft.

Verwendung von shelly-status-check.py

Das Python-Skript shelly-status-check.py dient zur Statusabfrage mehrerer Shelly-Geräte über ihre REST-API. Es liefert eine tabellarische Übersicht mit wichtigen Kennzahlen wie IP-Adresse, WiFi-Qualität und Uptime. Es kann zum Beispiel dazu genutzt werden, auf einen Blick herauszufinden wie gut die Wifi Verbindung ist, ob zum Beispiel der ECO Mode an ist oder Scripte auf dem Shelly Device installiert sind.

Installation

Python-Pakete installieren:

pip install requests tabulate

Oder auf Debian-basierten Systemen:

apt update && apt install python3-requests python3-tabulate

Skript herunterladen und ausführbar machen:

wget https://raw.githubusercontent.com/alaub81/shelly/main/shelly-status-check.py
chmod +x shelly-status-check.py

Gerätekonfiguration

IP-Adressen oder Hostnamen in Datei shellies.txt eintragen, z. B.:

shelly-kitchen.local
shelly-garage.local
192.168.1.42

Tipp: Automatische Generierung mit nmap:

nmap -sP 192.168.1.0/24 | grep "shelly" | awk '/Nmap scan report/ {print $5}' > shellies.txt

Ausführung

./shelly-status-check.py

Optionale Parameter

  • --file /path/to/shellies.txt – Ohne Parameter Default: ./shellies.txt
  • --sort ip – Sortiert alphabetisch nach IP/Host (Standard)
  • --sort uptime – Sortiert nach Betriebszeit (absteigend)
  • --sort wifi – Sortiert nach WiFi-Signalstärke (beste zuerst)

Beispiel:

./shelly-status-check.py --file /tmp/shellies.txt --sort uptime

Beispielausgabe

+---------------------------------------+---------------------+-------------+------------+------------+--------------+-------------+--------+-------------------+--------------------------------------------------------------+
| IP                                    | Device Typ          | Reachable   | Uptime     | Eco Mode   |   WiFi (dBm) | Bluetooth   | MQTT   | Debug UDP         | Scripts                                                      |
+=======================================+=====================+=============+============+============+==============+=============+========+===================+==============================================================+
| shelly-dl-ak.laubiot.loc              | Mini1PMG3 (Gen 3)   | ✅           | 15d 3h 52m | True       |          -67 | ❌           | ❌      | 192.168.50.20:514 | –                                                            |
+---------------------------------------+---------------------+-------------+------------+------------+--------------+-------------+--------+-------------------+--------------------------------------------------------------+
| shelly-dl-bu.laubiot.loc              | Mini1PMG3 (Gen 3)   | ✅           | 15d 3h 52m | False      |          -52 | ✅           | ❌      | 192.168.50.20:514 | oh-blu-scanner.js                                            |
+---------------------------------------+---------------------+-------------+------------+------------+--------------+-------------+--------+-------------------+--------------------------------------------------------------+
| shelly-dl-bz.laubiot.loc              | Plus1PMMini (Gen 2) | ✅           | 15d 3h 53m | True       |          -53 | ❌           | ❌      | 192.168.50.20:514 | –                                                            |
+---------------------------------------+---------------------+-------------+------------+------------+--------------+-------------+--------+-------------------+--------------------------------------------------------------+
| shelly-dl-carport.laubiot.loc         | Plus2PM (Gen 2)     | ✅           | 5d 9h 16m  | False      |          -80 | ✅           | ❌      | 192.168.50.20:514 | ble-shelly-motion.js, shelly-blumotion-darknight.js          |
+---------------------------------------+---------------------+-------------+------------+------------+--------------+-------------+--------+-------------------+--------------------------------------------------------------+

Verwendung von shelly-check.sh

Das Bash-Skript shelly-check.sh führt eine einfache Erreichbarkeitsprüfung für eine Liste von Shelly Gen2 Geräten durch. Es verwendet HTTP-Requests zum /rpc/Shelly.GetStatus-Endpoint und erkennt, ob ein Gerät online ist oder nicht.

Ideal für schnelle Tests oder regelmäßige Prüfungen per Cronjob in minimalistischen Umgebungen, z. B. auf einem Linux-Server ohne Python.

Installation

Das Skript benötigt nur ein installiertes curl:

apt update && apt install curl

Dann Skript herunterladen:

wget https://raw.githubusercontent.com/alaub81/shelly/main/shelly-check.sh
chmod +x shelly-check.sh

Geräte-Liste verwenden

Die IPs oder Hostnamen müssen in einer Datei namens shellies.txt aufgelistet sein (eine Zeile pro Gerät). Im Skript wird standardmäßig auf /root/shellies.txt zugegriffen:

192.168.10.101
192.168.10.102
shelly-garten.local

Tipp: Automatische Generierung mit nmap:

nmap -sP 192.168.1.0/24 | grep "shelly" | awk '/Nmap scan report/ {print $5}' > shellies.txt

Ausführung

Standardausführung (mit shellies.txt im selben Verzeichnis):

./shelly-check.sh

Oder mit benutzerdefinierter Datei:

./shelly-check.sh --file /etc/shelly/alle_geraete.txt

Funktionsweise

Das Skript sendet eine HTTP-Anfrage an den Status-Endpunkt jedes Geräts:

http://<IP>/rpc/Shelly.GetStatus

Ist eine Antwort mit "id": enthalten, gilt das Gerät als erreichbar. Nicht erreichbare Geräte werden als OFFLINE ausgegeben. Die Logzeile kann bei Bedarf in eine Datei geschrieben werden, z. B. durch Entfernen des Kommentars:

#>> /tmp/shelly_monitor.log

Cronjob Beispiel

Regelmäßige Prüfung alle 5 Minuten einrichten:

crontab -e

und diesen cronjob Zeile eintragen.

*/5 * * * * /path/to/shelly-check.sh --file /path/to/shellies.txt

Ist euer System in der Lage Cronjob Mails zu versenden, bekommt ihr immer, wenn ein Device nicht verfügbar ist eine Mail.

Verwendung von shelly-debug-setter.py

Das Skript shelly-debug-setter.py dient dazu, das UDP-Debug-Logging für eine Liste von Shelly Geräten zu konfigurieren. Es setzt die Zieladresse und den UDP Port für Debug-Nachrichten, sodass diese z. B. auf einem zentralen Syslog-Server empfangen werden können. Möchtet ihr einen eigenen Syslog-Server aufsetzen, so könnt ihr zum Beispiel diesen Anleitungen folgen:

Installation

Benötigte Pakete installieren:

pip install requests

Oder auf Debian-basierten Systemen:

apt update && apt install python3-requests

Skript herunterladen und ausführbar machen:

wget https://raw.githubusercontent.com/alaub81/shelly/main/shelly-debug-setter.py
chmod +x shelly-debug-setter.py

Geräte-Liste vorbereiten

Erstelle eine Datei mit den IPs oder Hostnamen der Geräte:

shellies.txt:

192.168.1.101
192.168.1.102
shelly-pro-kitchen.local

Tipp: Automatische Generierung mit nmap:

nmap -sP 192.168.1.0/24 | grep "shelly" | awk '/Nmap scan report/ {print $5}' > shellies.txt

Parameterübersicht

Argument Pflicht Beschreibung
--host Ja Ziel-IP oder Hostname für UDP-Debug-Logs (z. B. Syslog-Server)
--port Ja UDP-Port, z. B. 514 für Syslog
--file Nein Datei mit Geräten (Standard: shellies.txt)

Beispiel: Alle Geräte für Debug-Logging konfigurieren

./shelly-debug-setter.py --host 192.168.1.100 --port 514

Hinweise

  • Funktioniert ausschließlich mit Shelly Gen2+ Geräten (RPC-API erforderlich)
  • Geräte müssen im lokalen Netzwerk erreichbar sein
  • Authentifizierung wird aktuell nicht unterstützt – kann aber manuell im Script ergänzt werden

Verwendung von shelly-mqtt-config.py

Das Skript shelly-mqtt-config.py dient dazu, eine konsistente MQTT-Konfiguration für mehrere Shelly Geräte zentral zu setzen. Es überträgt die Konfiguration per HTTP an die Geräte und stellt sicher, dass alle korrekt mit dem MQTT-Broker verbunden sind. Solltet ihr noch keinen MQTT-Broker am Laufen haben, schaut hier:

Anwendungsfall

Dieses Skript ist hilfreich, wenn du in einer größeren Installation sicherstellen möchtest, dass:

  • alle Shelly-Geräte denselben MQTT-Broker nutzen,
  • eine einheitliche Topic-Struktur (z. B. shelly/device-name) verwendet wird,
  • die relevanten Optionen wie rpc_ntf oder enable_control aktiviert sind.

MQTT-Basis-Konfiguration im Skript

Die Konfiguration wird innerhalb des Skripts shelly-mqtt-config.py angepasst. Wichtige Felder:

base_config = {
    "enable": True,
    "server": "<MQTT-FQDN>:8883",  # ❗ DEIN MQTT-BROKER FULLY QUALIFIED HOSTNAME HIER EINTRAGEN
    "user": "<MQTT-USERNAME>", # ❗ DEIN MQTT-BENUTZER HIER EINTRAGEN
    "pass": "<MQTT-PASSWORD>",  # ❗ DEIN MQTT-PASSWORT HIER EINTRAGEN
    "ssl_ca": "*",
    "rpc_ntf": True,
    "status_ntf": True,
    "use_client_cert": False,
    "enable_rpc": True,
    "enable_control": True
}

Das Skript ergänzt automatisch:

  • client_id = Name/IP des Geräts
  • topic_prefix = z. B. shelly/shelly-kitchen

Installation

Benötigt wird nur das Python-Paket requests:

pip install requests

Das Skript kann aus dem GitHub-Repository heruntergeladen und ausgeführt werden:

wget https://raw.githubusercontent.com/alaub81/shelly/main/shelly-mqtt-config.py

chmod +x shelly-mqtt-config.py

Geräte-Liste vorbereiten

In der Datei shellies.txt muss jede Zeile eine IP-Adresse oder ein Hostname enthalten:

shelly-kitchen.local
192.168.1.102

Standardpfad im Skript: /root/shellies.txt – bei Bedarf anpassen. Tipp: Automatische Generierung mit nmap:

nmap -sP 192.168.1.0/24 | grep "shelly" | awk '/Nmap scan report/ {print $5}' > shellies.txt

Ausführung

./shelly-mqtt-config.py
# wenn nicht ./shellies.txt verwendet werden soll
./shelly-mqtt-config.py --file </path/to/shellies.txt>

Das Skript prüft automatisch die Rückmeldungen und startet jedes Gerät neu, nachdem die Konfiguration erfolgreich gesetzt wurde.

Hinweise

  • Funktioniert ausschließlich mit Shelly Gen2+ Geräten mit /rpc-API
  • Geräte müssen per HTTP erreichbar sein
  • Authentifizierung ist vorbereitet, aber standardmäßig deaktiviert:
  auth = None  # Beispiel: auth = ('admin', 'passwort')
  • Das Skript ist besonders nützlich in Kombination mit zentralem MQTT-Monitoring wie z. B. Home Assistant, Node-RED oder MQTT Explorer



Abgerufen von „https://www.laub-home.de/index.php?title=Shelly_Debugging_leicht_gemacht_–_Ausfälle_erkennen,_analysieren_und_vermeiden&oldid=9723“