Shelly Script Studio Troubleshooting: Häufige Probleme und Lösungen

Grundlagen: Wie Shelly Script Studio arbeitet

Bevor man Fehler sucht, muss man verstehen, wie die Shelly Script Engine funktioniert. Shelly Script Studio läuft direkt auf den Geräten der Plus- und Pro-Serie. Die Skripte basieren auf einer modifizierten JavaScript-Engine (Espruino/Mongoose OS) und werden lokal ausgeführt – ganz ohne Cloud. Das bedeutet: Wenn etwas nicht funktioniert, liegt die Ursache meist lokal – entweder im Code, in der Netzwerkverbindung oder an der Gerätekonfiguration. Ein Vorteil dieser Architektur: keine Cloud-Abhängigkeit, sehr kurze Reaktionszeiten und vollständige Kontrolle über die Logik. Der Nachteil: Wenn ein Skript abstürzt, sieht man das nicht sofort. Hier hilft das integrierte Debugging-Tool über Websocket, um Ausgaben und Fehler direkt mitzulesen. Typischer Aufbau:

• Ein Gerät (z. B. Shelly Plus 1) führt das Skript lokal aus.
• Das Skript reagiert auf Sensorwerte oder API-Events.
• Aktionen (z. B. Relais schalten) erfolgen direkt im Gerät.

Damit ist klar: Jede Automatisierung ist isoliert. Wenn also ein Skript hängt, betrifft das nur dieses eine Gerät – aber man muss sich auch auf dessen lokale Logik konzentrieren.

Skript startet nicht oder stoppt unerwartet

Das wohl häufigste Problem: Das Skript startet einfach nicht – oder läuft nur kurz und bricht dann ab. Hier gilt: Schrittweise vorgehen.

1. Autostart prüfen

Ein klassischer Stolperstein: Der Autostart ist nicht aktiviert. Im Web-Interface unter Scripts → Autostart sicherstellen, dass die Option „Bei Neustart starten“ aktiv ist. Ohne diese Einstellung wird das Skript nach einem Reboot nicht automatisch geladen.

2. Speichergrenzen beachten

Shelly-Skripte laufen in einer eingebetteten Umgebung mit begrenztem Speicher. Zu große JSON-Objekte oder lange Strings können den Interpreter an seine Grenzen bringen. Tipp: Variablen sparsam verwenden und unnötige Log-Ausgaben reduzieren.

3. Syntaxfehler im Code

Ein fehlendes Semikolon oder eine nicht geschlossene Klammer reicht aus, damit das Skript gar nicht startet. Aktiviert im Editor den Websocket-Debug und prüft die Konsolenausgabe. Dort werden Syntaxfehler direkt angezeigt.

4. Firmware prüfen

Nicht selten liegt das Problem an der Firmware-Version. Shelly veröffentlicht regelmäßig Updates, die Fehler in der Script Engine beheben. Also: Immer prüfen, ob die neueste Version installiert ist.

5. Neustart hilft tatsächlich

Ein einfacher Neustart kann hängende Prozesse oder Speicherlecks beseitigen. Klingt banal, ist aber oft die schnellste Lösung.

Skript läuft, aber reagiert nicht wie erwartet

Wenn das Skript zwar startet, aber nicht die erwartete Logik ausführt, liegt der Fehler meist in der Logik oder in der Kommunikation mit Sensoren oder APIs.

1. Ereignisse richtig abonnieren

Shelly arbeitet eventbasiert. Wird ein Ereignis (z. B. input.on('change', callback)) nicht korrekt abonniert, reagiert das Skript schlicht nicht. Prüft, ob die Eventnamen exakt mit der Dokumentation übereinstimmen.

2. Timing und Verzögerungen

Bei Automationen mit mehreren Aktionen hintereinander (z. B. Relais schalten, dann HTTP-Request) kann eine zu kurze Verzögerung (Timer.set()) dazu führen, dass Befehle verloren gehen. Hier hilft eine kleine Pause zwischen den Aktionen (z. B. 200–500 ms).

3. Sensorwerte prüfen

Wenn ein Skript auf Sensorwerte reagiert (Feuchtigkeit, Temperatur, Windgeschwindigkeit), überprüft zunächst, ob diese Werte tatsächlich aktualisiert werden. Über die REST-API oder MQTT kann man das leicht kontrollieren.

4. Netzwerkprobleme

Skripte, die HTTP-Requests oder MQTT verwenden, sind von der Netzwerkverbindung abhängig. Bei schwachem WLAN oder IP-Adresswechseln kann das Skript ins Leere laufen. Statische IPs und ein stabiler Access Point helfen hier enorm.

5. Testausgaben einbauen

Ein einfacher, aber effektiver Tipp: Baut print()-Ausgaben in kritische Codebereiche ein. So seht ihr im Websocket-Log genau, welche Bedingungen erfüllt werden und wo das Skript hängen bleibt.

Debugging mit Websocket und Logging

Die Debug-Konsole via Websocket ist euer bester Freund beim Fehlersuchen. Sie zeigt in Echtzeit, was euer Skript tut – oder eben nicht tut.

1. Aktivierung

Im Web-Interface unter Scripts → Debug über Websocket aktivieren. Danach öffnet sich ein Konsolenfenster, das alle print()-Ausgaben live anzeigt.

2. Schrittweise testen

Teilt große Skripte in kleine Abschnitte. Startet mit Basisfunktionen (z. B. nur Relais schalten) und fügt dann Schritt für Schritt mehr Logik hinzu. So isoliert ihr Fehlerquellen gezielt.

3. Fehlerbehandlung im Code

Nutzt try {... } catch (e) { print(e); }, um Laufzeitfehler abzufangen. Das verhindert, dass das Skript komplett abstürzt und gibt euch wertvolle Hinweise zur Ursache.

4. Permanente Logs

Da die Websocket-Konsole nur temporär ist, könnt ihr zusätzlich Log-Ausgaben über HTTP an einen lokalen Server oder Home Assistant senden, um sie dauerhaft zu speichern. So behaltet ihr auch bei längeren Tests den Überblick.

Typische Szenarien aus der Praxis

Ein paar Beispiele, die ich in den letzten Monaten häufiger gesehen habe – und wie man sie löst:

1. Lüftungssteuerung reagiert nicht mehr

Ursache: Sensor liefert keine neuen Daten. Lösung: Prüfen, ob der H&T noch im WLAN ist und seine Werte per REST-API aktualisiert. Alternativ Skript so anpassen, dass es auf Zeitintervalle statt Events reagiert.

2. Markisensteuerung fährt nicht ein

Ursache: Windwert wird nicht korrekt interpretiert. Oft liegt’s an der Einheit (km/h vs. m/s). Im Skript klarstellen, welche Einheit verwendet wird und ggf. konvertieren.

3. Gerät hängt nach einigen Tagen

Ursache: Speicherleck im Skript (z. B. Timer, die nicht gelöscht werden). Lösung: Timer sauber beenden (Timer.clear()) und zyklisch Speicherverbrauch prüfen.

4. Kein Zugriff auf HTTP-Endpunkte

Ursache: SSL oder Authentifizierung nicht berücksichtigt. Shelly-Skripte unterstützen HTTP, aber kein HTTPS mit Zertifikatsprüfung. Lösung: Lokale Bridge oder Proxy nutzen.

5. Skript läuft, aber Gerät reagiert träge

Ursache: Zu viele Log-Ausgaben oder blockierende Funktionen. Tipp: Asynchrone Aufrufe (Timer.set()) nutzen und Log-Frequenz reduzieren.

Best Practices für stabile Shelly-Skripte

Ein paar erprobte Tipps aus meiner täglichen Arbeit mit Shelly:

• Kleine Skripte statt Monsterlogik: Lieber mehrere kleine, spezialisierte Skripte pro Gerät als eine riesige Universal-Automation. Das erhöht die Stabilität und vereinfacht das Debugging.
• Regelmäßige Neustarts: Ein geplanter Neustart (z. B. einmal wöchentlich) kann helfen, Speicherprobleme zu vermeiden.
• Logging sparsam einsetzen: Zu viele Ausgaben verlangsamen das System. Nur relevante Informationen loggen.
• Firmware aktuell halten: Shelly behebt regelmäßig Script-bezogene Fehler mit Updates. Ein veraltetes System ist oft die Ursache für seltsames Verhalten.
• Community nutzen: Im offiziellen Shelly-Forum oder auf GitHub findet man viele Beispielskripte und Lösungen – gerade bei kniffligen Problemen ein echter Zeitgewinn.

Mit diesen Grundsätzen laufen eure Automationen deutlich stabiler – und ihr verbringt weniger Zeit mit Fehlersuche.