Skripte (remote) auf Inaktivität testen

Hinweis zur Nutzung von Skripten (für Nutzer)

Die Verwendung von Skripten erfolgt ausdrücklich auf eigene Gefahr. Weder Shelly noch die jeweiligen Autoren oder Entwickler der Skripte übernehmen irgendeine Form der Haftung für mögliche Schäden, Fehlfunktionen, Datenverluste oder anderweitige Beeinträchtigungen, die durch die Nutzung dieser Skripte entstehen könnten. Bitte stellen Sie vor dem Einsatz sicher, dass Sie den Quellcode verstehen und sich der möglichen Auswirkungen bewusst sind. Die Skripte werden ohne Gewähr bereitgestellt und unterliegen keiner regelmäßigen Wartung oder offiziellen Unterstützung.


Hinweis für Entwickler

Wenn Sie eigene Skripte bereitstellen, achten Sie bitte darauf, eine klare Beschreibung, eventuelle Einschränkungen und Sicherheitsaspekte zu dokumentieren. Beachten Sie zudem, dass Nutzer Ihre Skripte grundsätzlich auf eigenes Risiko verwenden. Eine Haftung für Schäden ist ausgeschlossen, sofern diese nicht vorsätzlich oder grob fahrlässig verursacht wurden oder gesetzlich anderweitig geregelt ist.

VPN/Proxy erkannt

Es scheint, dass Sie einen VPN- oder Proxy-Dienst verwenden. Bitte beachten Sie, dass die Nutzung eines solchen Dienstes die Funktionalität dieser Webseite einschränken kann.

  • Bekanntermaßen bieten Shelly Skripte erheblich mehr Einsatzmöglichkeiten, als es Standardkonfigurationen erlauben. Soviel zum entscheidenden Vorteil.

    Der Nachteil von Skripten besteht in einer mitunter mangelhaften Ausfallsicherheit, soll heißen: Ein Skript kann, aus welchen Gründen auch immer, inaktiv sein - also ruhen. Wenn ein Skript nicht ruhen darf, es aber tut, dann ist es hilfreich, automatisiert darüber informiert zu werden. Dafür habe ich ein Skript geschrieben, welches bei Bedarf über Nichtaktivitäten von Skripten via callmebot.com informiert. Ich nutze dafür den Messengerdienst Signal, es können aber afaik auch andere Messenger genutzt werden.

    Das Skript bietet insbesondere eine Funktion checkScripts() , welche praktikabel per Zeitpläne (schedule jobs) aufgerufen werden sollte - bspw. alle 30 Minuten. Diese Funktion kann je nach Parameter lokal oder remote (besonders zweckmäßig) bestimmte Skripte auf Inaktivität prüfen. Falls der remote Host nicht erreichbar ist oder mindestens eines der zu prüfenden Skripte inaktiv ist, wird eine Messenger Nachricht via callmebot.com gesendet.

    Dies habe ich bisher auf einer Shelly Pille entwickelt und getestet.

    Optionales Vorhaben: Falls Internet nicht verfügbar, können solche Meldungen im nichtflüchtigen Speicher protokolliert und zeitversetzt bei Bedarf angeschaut werden.

    Beispiel einer solchen Nachricht

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    Erstellen eines geeigneten Schedule Jobs via tools.eichelsdoerfer.net

    Da mit Shelly Bordmitteln ein benötigter Job nicht erstellbar ist, habe ich dafür eine Website zusammengestellt, welche das Anlegen oder ändern nützlicher Jobs unterstützt.
    https://tools.eichelsdoerfer.net/schedjob.html

    Beispiel eines hier geeigneten Jobs

    Dieser Screenshot zeigt das Anlegen bzw. Ändern eines Zeitplans zum regelmäßigen Aufruf der Skriptfunktion checkScripts().

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    Mein noch folgendes Skript hat die Skript Id 4. Der Job ruft die Funktion checkScripts() alle 5 Minuten auf. Diese relativ hohe Abfragefrequenz ist ausschließlich dem Testen geschuldet. Niemand dürfte daran interessiert sein, alle 5 Minuten eine Nachricht zu erhalten, welche denselben Ausfall mittteilt. Der timespec Wert kann gerne auch völlig anders gestaltet werden. Dieser ist auch via Shelly WebUI leicht abänderbar. Nur der Aufruf von checkScripts() kann nicht via WebUI eingebaut werden.

    Die Parameter des Funktionsaufrufs - am Beispiel erläutert

    1. IP Adresse des remote Skripthosts - wichtig(!) in Hochkommata gesetzt
      Wird hier 'local' oder 'localhost' oder '127.0.0.1' eingesetzt, fragt das Skript unmittelbar lokal ab, andernfalls per HTTP.Get. Im Beispiel hat der Host die IP Adresse 172.16.3.23.
    2. Die Id des zu prüfenden (remote) Skripts. Hier ist nur eine Id (1) verwendet. Stattdessen kann auch eine Liste (Array) genutzt werden, bspw. [1,3,4] womit die Skripts mit den Ids 1, 3 und 4 auf Inaktivität geprüft werden.
      Welche Skripte zu prüfen sind, kann nur der Anwender entscheiden.
    3. Optionaler Zeitversatz in Sekunden, hier 10s. Er bietet die Möglichkeit, zur selben Zeit mehrere Aufrufe von checkScripts() zu nutzen, welche das tatsächliche Prüfen unterschiedlich zeitversetzt durchführen. Dies kann in mehreren Jobs oder auch in einem Job mit mehreren calls erfolgen. Bei geeigneter Planung kann dieser optionale Zeitversatz den Abbruch meines Skripts wegen zu vieler gleichzeitiger RPC Aufrufe verhindern. Hier sollten wenige Sekunden völlig ausreichen. Fehlt dieser Parameter, wird die Prüfung sofort abgearbeitet.
      Bsp: checkScripts('172.16.3.23', 1)

    Das Skript (zum Prüfen von Skripts ;))

    Man benötigt einen kostenfreien Account auf callmebot.com. Damit muss der Wert von HttpCode für eigene Zwecke angepasst werden.

    Das Skript gibt im Console Fenster wenige Informationen aus, was leicht abgestellt werden kann.

    Hinweis zu den via callmebot.com übertragenen Texten

    Darin darf kein Leerzeichen stehen. Stattdessen muss jeweils ein Pluszeichen vorhanden sein.

    Anlass

    In unserem alten, kleinen Wintergarten hängt ein Heizkörper, der normalerweise verlässlich via Shelly Plus 1 und Skript vor dem Einfrieren - Zieltemperatur 5°C - geschützt wird. Dieser Shelly verlor in letzter Zeit wiederholt die WLAN Verbindung, trotz guter Feldstärke - vermutlich ein Hardwaredefekt. Der Ersatz Shelly Plus 1 tut bisher verlässlich seine Dienste. Ich möchte aber darüber informiert werden, wenn hier ein Problem vorliegen sollte. Solches erledigt obiges Skript in Kombination eines Schedule Jobs - derzeit auf einer Shelly Pille.

    Nebenbemerkung: Die alten, üblichen, mechanischen Thermostate sind wenig geeignet, da sie nicht für solch niedrige Zieltemperaturen gebaut sind. Dies verursachte früher leider oftmals einen zu warmen Heizkörper, also verschwendete Energie. Ein dort montierter TRV fiel aus. Dies veranlasste mich dazu, eine verlässlichere Implementation via Skript zu entwickeln, die standalone nutzbar ist.

    Edit:

    Das Skript kann auch ohne bereits vorhandenen callmebot.com Account getestet werden. Die Ausgaben im Console Fenster zeigen, ob ein inaktives Skript gefunden wurde. Steht hinter der Ausgabe "... Inaktive+Skripte:" nichts, wurden keine der zu prüfenden Skripte als inaktiv gefunden und bei einer remote Prüfung wurde kein Problem festgestellt.

    Btw, falls ein zu prüfendes Skript (dessen Id) nicht vorhanden ist, wird die Meldung "missing script:<Id>" ausgegeben und gesendet.

    An Cloud-/Szenen-Benutzer (insbesondere für Regelungen): Was erwartest du, wenn Internet oder Cloud sabotiert werden? Nicht nur dafür meine kleine Skripteinführung  8)

    Die einzig existierende Konstante ist der Wandel. Oft liegt die größte Schwierigkeit darin, das Anliegen des Klienten zu verstehen.

    7 Mal editiert, zuletzt von eiche (1. Februar 2026 um 05:22)

  • eiche 31. Januar 2026 um 22:17

    Hat den Titel des Themas von „Skripte (remote) auf Aktivität testen“ zu „Skripte (remote) auf Inaktivität testen“ geändert.
  • Dazu beispielhaft zwei getestete Schedule Jobs

    Im Einsatz:

    1. Eine Pille by Shelly mit Name "Die Pille" (kurz Pille)
    2. Ein Shelly Plus 1, den ich "SHT-Wintergarten" (kurz SHT) nenne - SHT von Shelly Humidity Temperature, weil als Sensor ein DHT22 genutzt wird

    Der SHT regelt die Temperatur via Skript und ist zu überwachen - hier vorläufig von der Pille. Auf beiden läuft obiges Skript "scriptcheck.js".

    Die Pille prüft derzeit ausschließlich das Regelungsskript auf dem SHT, der SHT prüft sein Regelungsskript und scriptcheck.js auf der Pille. Diese Anwendung ist somit redundant ausgelegt.

    Der Schedule Job auf der Pille

    Alle 30 Minuten wird remote das Skript Id 1 (=Regelungsskript) auf dem SHT mit IP Adresse 172.16.3.23 geprüft. Das Skript "scriptcheck.js" hat die Id 4.

    Der Schedule Job auf dem SHT

    Hier hat scriptcheck.js die Id 3. Alle 30 Minuten wird auf dem SHT zweimal die Funktion checkScripts() aufgerufen.

    • mit lokaler Prüfung seines Regelungsskripts mit der Id 1 ohne Zeitversatz ,
    • mit ferner Prüfung des Skripts scriptcheck.js (Id 4) auf der Pille mit IP Adresse 172.16.8.2 mit Zeitversatz von 5s.

    Beide Prüfungen werden somit gleichzeitig initiiert, die ferne Prüfung aber um 5s verschoben. Diese Verschiebung dient dazu, eine Häufung von gleichzeitig laufenden RPC zu vermeiden, was zu Skriptstopps führen kann. Da auf dem SHT bis zu 8 Zeitpläne für die Heizung vorgesehen sind, werde ich wohl in beiden Aufrufen zwei unterschiedliche Zeitversatze einbauen.

    Wozu dieser Aufwand?

    Auf diese Weise prüft der Geprüfte (SHT) seinen fernen Prüfer (Pille). Fällt einer von beiden oder das entscheidende Regelungsskript aus, erhalte ich eine aussagekräftige Nachricht, sofern dazu Internetzugang verfügbar ist. Fehlt dieser Zugang, soll zukünftig die zu sendende Nachricht lokal im nichtflüchtigen Speicher abgelegt werden. Daran werde ich noch arbeiten.

    An Cloud-/Szenen-Benutzer (insbesondere für Regelungen): Was erwartest du, wenn Internet oder Cloud sabotiert werden? Nicht nur dafür meine kleine Skripteinführung  8)

    Die einzig existierende Konstante ist der Wandel. Oft liegt die größte Schwierigkeit darin, das Anliegen des Klienten zu verstehen.

    Einmal editiert, zuletzt von eiche (2. Februar 2026 um 17:30)

  • So, es liegt die vorläufig letzte Version des Skripts "scriptcheck.js" vor.

    Zur Erinnerung: Dieses Skript dient keiner Anwendung sondern soll den Anwender via Nachricht informieren, wenn eines oder mehrere notwendigerweise laufende (remote) Skripte gestoppt sind. So ist das Problem relativ zügig erkennbar und kann angegangen werden. Es ist grundsätzlich nicht möglich, dass ein Skript wegen eines Fehlers nicht gestoppt werden kann. Mit "try ... catch" lassen sich einige Fehler auffangen, aber nicht alle.

    Diese Version speichert die Nachricht in einer nicht ausführbaren Skriptdatei anhängend, wenn das Senden via callmebot.com aus technischen Gründen fehlschlägt. Diese nicht ausführbare Skriptdatei muss der Anwender anlegen und deren Id in scriptcheck.js hinter LogId eintragen. Ich habe bewusst darauf verzichtet, beim Start des Skripts nach der Id eines "Skript" namens "log" suchen zu lassen. Die Nutzung meines Skripts ist nicht für DAUs gedacht. Die Protokolldatei kann als Skript geöffnet und gelesen werden. Nach einer hinreichenden Analyse des Inhalts sollte sie bis auf ein einzelnes Zeichen am Anfang geleert werden. Das Anfangszeichen ist erforderlich, weil ein komplettes Leeren nicht gelingt. Statt eines Zeichens, kann auch gerne eine komplette Zeile am Anfang stehen, wie "logfile of scriptcheck.js". Solange das Versenden via callmebot gelingt, wird nichts in diese Datei geschrieben.

    Das Skript "scriptcheck.js"

    Die Werte für Phone und APIKey sind anwenderbezogen (nach Erhalt des callmebot Accounts) einzutragen! Wer dieses Skript testen will, kann es auch mit den x-en (ohne gültige Account Daten) tun. Dann landen die Nachrichten im script:<LogId>, also der Protokolldatei für Notfälle.

    Wenn ein Fehler im zu sendenden Text - bspw. ein Leerzeichen - vorliegt, sendet callmebot diesen Text nicht. Dann liegt ein (aktuell nicht vorhandener) Fehler in der Textzusammensetzung des Skripts vor, was kein Grund ist, diesen irgendwo zu speichern, weil dies keinen technischen Grund hat. Dann ist derjenige gefordert, den Fehler zu beheben, der ihn verursacht hat.

    Bei Fragen dazu werde ich gerne versuchen darauf einzugehen.

    An Cloud-/Szenen-Benutzer (insbesondere für Regelungen): Was erwartest du, wenn Internet oder Cloud sabotiert werden? Nicht nur dafür meine kleine Skripteinführung  8)

    Die einzig existierende Konstante ist der Wandel. Oft liegt die größte Schwierigkeit darin, das Anliegen des Klienten zu verstehen.

  • Hallo eiche,

    danke für diesen sehr interessanten Beitrag. Da sich bei mir auch schon an die 30 Skripte auf 20 Geräten angehäuft haben, ist diese Art der Überwachung eines gestoppten Scripts sehr wertvoll. Besonders interessant ist für mich die Idee mit der Scriptdatei, da ich mich auch schon öfters gefragt habe, wo ich Informationen speichern soll, wenn callmebot aufgrund zu vieler Meldungen aufhört Nachrichten zu übermitteln. Werde ich auf jeden Fall übernehmen.

    Besten Dank.

  • joma0815

    Es freut mich, wenn ich nicht der einzige Anwender bin.

    wenn callmebot aufgrund zu vieler Meldungen aufhört Nachrichten zu übermitteln.

    Es bleibt zu prüfen, was ggf. callmebot dann rückmeldet. Bisher habe ich ausschließlich auf Nichterreichbarkeit und Nichtauflösbarkeit Name -> IP Adresse getestet und beide Fehlercodes berücksichtigt (-104 und -114). Vielleicht ist die Abfrage auf diese Codes noch ein wenig zu erweitern. Das wird die Nutzung zeigen.

    Wenn du viele Skripte auf diese Weise überwachen willst, vielleicht scriptcheck.js nur auf wenigen (ein oder zwei) Geräten nutzend, dann kannst du bspw. bis zu vier Methoden calls je Schedule Job mit jeweiligem Zeitversatz konfigurieren. Da auf einem Gerät viele Schedule Jobs aktiv sein können, bietet sich eine hohe Anzahl an potentiellen Überwachungszielen. Zwei Shelly mit scriptcheck.js können sich zusätzlich gegenseitig überwachen. Das sollte genügend Redundanz ergeben.

    An Cloud-/Szenen-Benutzer (insbesondere für Regelungen): Was erwartest du, wenn Internet oder Cloud sabotiert werden? Nicht nur dafür meine kleine Skripteinführung  8)

    Die einzig existierende Konstante ist der Wandel. Oft liegt die größte Schwierigkeit darin, das Anliegen des Klienten zu verstehen.

  • Dieses Thema enthält 4 weitere Beiträge, die nur für registrierte Benutzer sichtbar sind.