Beiträge von eiche

Auch wenn die Lösung von SebMai vermutlich das vom TE Gewünschte abdeckt, so habe ich trotzdem für weiterführende Zwecke meine Webseite zum flexiblen nutzen von Schedule Jobs überarbeitet.

Nun bietet sie folgendes.

1. Anlegen von Schedule Jobs (Zeitplänen), welche nicht per WebUI der Shellies angelegt werden können.
2. Ändern von solchermaßen angelegten Schedule Jobs.
3. Entfernen jeglicher Schedule Jobs - einzeln.
4. Wer sich mit der Syntax zum Eintrag timespec beschäftigt, kann alle Möglichkeiten dieser Schedule Jobs und der Methode "Script.Eval" nutzen.
   Dazu zählen sunrise, sunset (auch mit Offset), auf bestimmte Wochentage einschränken, auf bestimmten Monatstag festlegen, auf Jahresdatum (Monat, Tag) festlegen.
5. Der Anwender dieser Website kann daran die Syntax des entsprechenden URL analysieren und kennenlernen, muss es aber nicht.

Diese Website unterstützt somit die Verwendung der Kombination von Skripten und Schedules. Vielleicht kann sie noch nützlich sein.

Der Link: https://tools.eichelsdoerfer.net/schedjob.html

Ich empfehle für diese Webseite die Nutzung des Firefox Browsers, weil dieser die Antworten, insbesondere die Listings, übersichtlich darstellt.

Bei Fragen hierzu stehe ich gerne zur Verfügung.

Jo, das ist in der WebUI nicht wählbar.

Da sollte ich meine o.a. Webseite noch überarbeiten, damit sunrise und sunset genutzt werden können.

Stimmt, so sollte es gehen.

So, nun steht eine Webseite zur Verfügung, die folgendes bietet.

1. Anlegen von Schedule Jobs (Zeitplänen), welche nicht per WebUI der Shellies angelegt werden können.
2. Ändern von solchermaßen angelegten Schedule Jobs.
3. Entfernen jeglicher Schedule Jobs - einzeln.
4. Es ist derzeit ausschließlich die Methode "Script.Eval" in diesen Jobs vorgesehen.
5. Der Anwender dieser Website kann daran die Syntax des entsprechenden URL analysieren und kennenlernen, muss es aber nicht.

Diese Website unterstützt somit die Verwendung der Kombination von Skripten und Schedules.

Der Link: https://tools.eichelsdoerfer.net/schedjob.html

Bei Fragen hierzu stehe ich gerne zur Verfügung.

Edit: Ich empfehle für diese Webseite die Nutzung des Firefox Browsers, weil dieser die Antworten, insbesondere die Listings, übersichtlich darstellt.

Das Einrichten der Schedule Jobs gelingt dann mit

http://<Shelly_IP-address>/rpc/shedule.create?timespec="0 0 22 * * *"&calls=[{"method":"script.eval","params":{"id":1,"code":"enable(false)"}}]

Dieser Job ruft täglich um 22 Uhr die Funktion enable(false) im Skript mit der Id 1 auf - da du nur ein Skript nutzt, möglichst ohne zusätzliche Experimente in anderen Skripts, hat dieses die Id 1. Diese Id kann man aber auch ermitteln ...

Der zweite Schedule Job wird genau gleich angelegt, nur mit der Freigabezeit in timespec und dem Parameterwert true hinter enable (am Ende).

Man kann dies auch kombinieren mit sunrise und sunset ... siehe hierzu: https://github.com/mongoose-os-libs/cron

Vielleicht sollte ich gelegentlich eine Webseite erstellen, die man leicht zum Anlegen/Ändern eines solchen Schedule Jobs nutzen kann. Ich habe so etwas für ein Projekt getan, was aber nicht allgemein verwendbar ist.

Mal sehen ...

Edit:

Wenn du später die Freigabe/Sperren-Zeiten ändern willst genügt folgendes:

http://<Shelly_IP-address>/rpc/shedule.update?id=1&timespec="0 30 22 * * *"
bzw.
http://<Shelly_IP-address>/rpc/shedule.update?id=2&timespec="0 15 7 * * *"

Die Id-Werte sind die der beiden Schedule Jobs, Job 1 zum sperren des Schaltens, Job 2 zum freigeben des Schaltens.

Edit: Siehe auch Post #50

Code-Beispiel:

let EN = true; // Voreinstellung

function enable(en) { EN = en; }

Shelly.addEventHandler(
    function(e) {
        print(JSON.stringify(e));
        // feststellen, welches Ereignis (e) vorliegt und passend selektieren, ich habe das Gerät nicht zum testen
        // Id des Eingangs und dessen Zustand feststellen
        let InpId = ...;
        let InpStat = ...;
        if(EN) Shelly.call("Switch.Set", {id:InpId, on:InpStat});
    }
);

Edit:

Diese Vorlage kannst du nutzen, allerdings ist die eintreffende Ereignis-Struktur (im JSON-Format) zu analysieren, um auf Grund dessen

1. nicht passende Ereignisse wegzufiltern und
2. wenn Ereignis passt, die beiden Werte für InpId und InpStat zu erhalten.

Ich habe noch die Ausgabe der gesamten Event-Information (Parameter e) eingebaut - siehe print-Anweisung.

Die täglich temporäre detached-Lösung fiel mir auch zunächst ein.

Nachteil: Es wird täglich in den nichtflüchtigen Speicher geschrieben. Das ist zwar nicht schlimm, aber vermeidbar, wenn man will.

Hier kommt mal wieder meine Vorliebe in Frage: Kombination aus Skript und Schedule Jobs

Prinzip:

Die Eingänge werden fest auf detached konfiguriert.

Das Skript enthält

1. einen Eventhandler, der auf die Änderungen der Eingangssignale reagiert,
2. eine Funktion enable(en), welche eine Skript-globale boolesche Variable EN auf den Wert des Parameters "en" setzt.

Dazu werden zwei Schedule Jobs mit den passenden timespec-Einträgen, der Methode Script.Eval und dem Aufruf der Funktion enable() eingerichtet,

der eine Job mit enable(false). der andere mit enable(true). Dies gelingt NICHT mit der WebUI, hier ist bspw. ein passender URL erforderlich.

Der Eventhandler prüft den Wert von EN und lässt den dem Eingang zugeordneten Ausgang (gleiche Id) nur dann schalten, wenn EN true ist.

Infos zu Scripts: https://shelly-api-docs.shelly.cloud/gen2/Scripts/S…anguageFeatures

Infos zu Schedules: https://shelly-api-docs.shelly.cloud/gen2/Component…rvices/Schedule

Bei Bedarf kann ich konkreter werden.

Eine Zentrale mit dem Raspberry Pi ist sehr nützlich.

Ich nutze darauf kein fertiges Smart Home System, sondern Mosquitto, Node-RED, InfluxDB, Grafana und ein paar Shellskripte, die aber nicht notwendig sind.

Diese Zusammenstellung bietet alles, was ich mir als zweckmäßig vorstellen kann.

Allerdings muss man sich zur Nutzung in die drei letzten Werkzeuge mehr oder weniger einarbeiten.

Ich nutze deshalb kein fertiges System, weil ich so am flexibelsten bin. Das, was ich bisher implementierte kann afaik kein fertiges System nach meinen Wünschen.

Man kann afaik zumindest teilweise die o.a. Werkzeuge auch in ein fertiges System zusätzlich einbetten.

Vielleicht hilft die dies zur Orientierung.

Noch viel Erfolg ...

Wenn du zu deinem o.a. Ziel und meiner Implementationsidee noch Fragen hast, kontaktiere mich einfach!

Vermutlich beinhaltet der Pro 3EM einen ESP32, ich habe kein solches Gerät.

Laut Beschreibung kann er Skripte abarbeiten. https://shelly-api-docs.shelly.cloud/gen2/Devices/ShellyPro3EM

Daraus sollte sich folgende Implementationsmöglichkeit ergeben:

1. Erstellen eines kurzen Skripts mit zwei Funktionen
   1. Eventhandler nimmt den jeweils aktuellen (strukturierten) Wert entgegen und speichert diesen in einer globalen Variablen im Skript (RAM)
   2. Senden einer MQTT-Nachricht (Beispielname send()), welche den/die gewünschten Werte in der Payload, ggf. JSON, sendet.
      Das MQTT Topic kannst du nach deinen Wünschen selbst wählen.
2. Einrichten eines Schedule Jobs mit timespec="*/20 * * * * *" und der Methode Script.Eval zum aufrufen von send().

Damit wird alle 20s eine MQTT-Nachricht mit den zuletzt erfassten Werten gesendet.

Zu den Schedule Jobs siehe https://shelly-api-docs.shelly.cloud/gen2/Component…rvices/Schedule

Bei Bedarf kann ich noch konkreter werden.

Edit: Die vorgegebenen MQTT Nachrichten werden dann zwar gesendet, es gibt dann aber keinen Subscriber dafür, wenn dein Topic (im Skript) vom vorgegeben/konfigurierten Topic abweicht.

Edit 2: Ich nutze sehr gerne die Android App "mqtt dash". Sie hat eine relativ schlichte Oberfläche, ist aber sehr flexibel nutzbar. Die "iot mqtt Panel" will ich mir mal ansehen.

Edit 3: s.a. RE: Kombinierte Zeit-/Bewegungssteuerung zur Unterstützung beim Anlegen von Schedule Jobs, Post #50

Noch eine Möglichkeit ...

Ich nutze dafür Shelly i4 mit dazu passenden 4fach Tastflächen.

Hierzu nutze ich ein Skript auf dem i4, an den Rollladen-Shellies habe ich keinen Taster angeschlossen.

Vorteile:

• Ich kann die 4fach Taster an einer günstigen Stelle einbauen.
• Damit kann ich zwei Rollläden steuern.
• Im Skript kann ich weitere Tasterfunktionalitäten implementieren, was ich auch tat.

Nachteil: Solange WLAN ausfällt, kann ich meine Rollläden nicht bedienen - kam bisher nicht vor.

Vermutlich gelingt der Einsatz des i4 für diesen Zweck auch per Konfiguration ohne Skript.

ostfriese

Danke

Nachgereicht:

Den Status eines Ausgangs per Methode "Switch.GetStatus", siehe auch https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/Switch

Shelly.call("switch.getstatus", {id:<Id des Ausgangs>},
    function(status) {Out[<Id des Ausgangs>] = status.output;} // nach Doku, Struktur nicht geprüft
)

Du kannst ein solches Resultat leicht abfragen per

http://<shelly_IP-address>/rpc/switch.getstatus?id=<Id des Ausgangs>

Der Firefox zeigt das JSON-Resultat gut lesbar an.

Soeben geprüft - die Struktur stimmt -> obiger Code ( = status.output) muss passen.

Edit: WICHTIG! Unbedingt beachten.

Eine Abfrage per RPC bzw. Shelly.call ist immer asynchron, d.h. es ist unbekannt, wann die Methode das Resultat (hier status) liefert. Dann kann einige ms dauern.

Deshalb muss das Resultat zwecks späterer Verwendung gespeichert werden oder etwas mit dem Eintreffen des Resultats in der callback Funktion ausgeführt werden.

Notfalls kann man nach dem RPC Aufruf einen Timer für einige ms starten und in dessen callback Funktion das gespeicherte Resultat verarbeiten. Dies ist allerdings nur eine Notlösung und nicht empfehlenswert, wenn es anders gelingt.

Obiger Code lässt sich auch sehr gut in Funktionen unterbringen und so die Usability beim Coden steigern.

let Out = [null, null, null, null]; // Für jeden Ausgang einen null Eintrag - ANPASSEN!

function switchAll(OnOff) {
    for (let i=Out.length-1; i>=0; --i) {
        Shelly.call("Switch.Set",{ id: i, on: OnOff });
        Out[i] = OnOff;
    }
}

// Resultat: null, wenn nicht alle Ausgänge gleich sind, andernfalls der Status der Ausgänge
function checkAll() {
    let all = Out[0];
    let equ = true;
    for (let i=Out.length-1; i>0 && equ; --i) equ = Out[i]===all; // oder equ = Out[i]===all ? true : false
    return equ ? all : null;
}

// Anwendung von checkAll:
let Stat = checkAll();
if (Stat!==null) {
    // In Stat liegt der gleiche Status aller Ausgänge.
    //...
}

Edit: Code in checkiAll hinter return leicht verbessert im Sinne der Verständlichkeit. ... und geringfügig gekürzt

Prinzip:

Dort, wo eindeutig geschaltet wird lässt du den Status des jeweiligen Ausgangs in einer globalen Struktur speichern.

Dies gelingt ausschließlich beim toggeln nicht. Dort kannst du den Status per Methode "Switch.GetStatus" abfragen und den Status in der callback-Funktion speichern.

Alternative: Du lässt mit dem Start des Skripts alle Ausgänge abfragen und speicherst deren Status in der Struktur. Dann geht auch beim toggeln das synchrone Speichern, solange der Shelly fehlerfrei arbeitet und sich keine Störung ereignet.

Als Struktur bietet sich ein Datenfeld (Array) mit so vielen Elementen an, wie der Shelly Ausgänge besitzt.

Beispiel: Nicht geprüft, aber vermutlich fehlerfrei und funktionstüchtig.

let Out = [null, null, null, null]; //für 4 Ausgänge, zugleich wird length im Code genutzt
//...
//an entsprechender Stelle
let OutStat = false; // bzw. beim Einschalten true
for (let i=Out.length-1; i>=0; --i) {
    Shelly.call("Switch.Set",{ id: i, on: OutStat }); // optionale Parameter brauchen kein null
    Out[i] = OutStat;
}
// zum prüfen, ob alle Ausgänge aus sind
let all = false;
let i;
for (i=Out.length-1; i>=0 && !all; --i) all = Out[i];
if (i<0) ... // Alle Ausgänge sind aus.

Wenn du weitere Infos brauchst, lasse es mich wissen!

TomyH

Widerspruch!

Im Alter wird auch manches leichter, solange man flexibel und lernbereit ist.

Edit: ... und ein bisschen experimentierfreudig.

Zum abrunden der Möglichkeiten eine Zusammenstellung, die

• die Schreibzugriffe in den nichtflüchtigen Speicher auf das notwendige Maß reduziert,
• sehr einfachen Skriptcode enthält und
• sehr zuverlässig arbeitet.

1. Alle Schedule Jobs auflisten lassen, auch und insbesondere solche, die nicht per WebUI konfiguriert wurden. Insbesondere der Web Browser Firefox listet diese Jobs (JSON-Format) übersichtlich auf.
   http://<shelly_ip-address>/rpc/schedule.list
2. Das einfache Skript:
   Es beinhaltet
   1. die globale Variable Status zur Speicherung des Status des digitalen Eingangs für synchronen Zugriff,
   2. das Eventhandling zu Änderungen des digitalen Eingangssignals,
   3. die Funktion switch_conditional() zum bedingten Einschalten des Ausgangs.

let Status = { // kann leicht erweitert werden
  DigInp : null
};

Shelly.addEventHandler( // kann leicht erweitert werden
  function(e) {
    let comp = e.info.component;
    if (comp==="input:100") {
      print("Digital Input: ", e.info.state); // kann entfallen, nur Kontrollausgabe
      Status.DigInp = e.info.state;
    }
  }
);

function switch_conditional() { // schaltet den Ausgang nur dann ein, wenn digitaler Input ein (true) ist
    if(Status.DigInp!==null && Status.DigInp) Shelly.call("switch.set", {id:0, on:true});
}

Um dieses Skript nutzen zu können, sind Möglichkeiten von Schedule Jobs zu nutzen, die nicht in der WebUI zur Verfügung gestellt sind.

Ein geeigneter Schedule Job kann wie folgt angelegt werden:

http://<shelly_ip-address>/rpc/schedule.create?enable=true&timespec="0 15 17 * * *"&calls=[{"method":"script.eval","params":{"id":1,"code":"switch_conditional()"}}]

Dieser Job ruft täglich um 17:15 Uhr die Funktion switch_conditional() im Skript mit der Id 1 auf. enable=true kann auch weggelassen werden, weil dies die default Einstellung ist.

Die Syntax zu timespec ist hier zu finden: https://github.com/mongoose-os-libs/cron

Ich setzte für weiteres voraus, dass dieser Schedule Job die Id 1 besitzt.

Wenn die Schaltzeit geändert werden soll, kann die Methode Schedule.Update verwendet werden:

http://<shelly_ip-address>/rpc/schedule.update?id=1&timespec="0 30 12 * * *"

Dies ändert den Schedule Job mit der Id 1 so, dass täglich um 12:30 Uhr die Funktion switch_conditional() aufgerufen wird.

Man kann einen Schedule Job leicht Wochentags spezifisch einrichten. Soll bspw. der obige Schedule Job (Id 1) nur montags und mittwochs aktiv sein, ist folgendes Update zielführend:

http://<shelly_ip-address>/rpc/schedule.update?id=1&timespec="0 30 12 * * Mon,Wed"

Auch kann sunrise und sunset in timespec verwendet werden.

Da diese URLs etwas kryptisch sind, kann die usability per passend zusammengestellter Website unterstützt werden.

In diese können die variierbaren Parameter für timespec per Eingabefelder eingegeben oder per Auswahllisten selektiert werden.

Eine solche Website kann

• lokal auf dem Benutzer-Endgerät (Notebook, Tablet, Smartphone) oder
• im world wide web platziert werden.

Ich betone, dass dies eine Implementationsvariante ist, welche nicht von der derzeitigen WebUI-Konfiguration unterstützt wird, aber technische Vorteile gegenüber der interessanten Lösung von ostfriese besitzt.

Dessen Variante hat den Vorteil, dass die per WebUI konfigurierbaren Schedule Jobs (höhere usability) genutzt werden können. Es sind aber dieselben Schedule Jobs wie die per RPC (s.o.) eingerichteten. Diese Konfiguration ist nur eingeschränkt und nutzt nicht alle Möglichkeiten des in der Firmware enthaltenen Betriebssystems.

Edit:

Skript für den Zweck des TE geringfügig korrigiert.

TomyH

Mein Workaround per HTTPServer.registerEndpoint() testete ich vorhin erstmalig.

Auch bin ich nicht sicher, ob die Benutzer-Konfiguration von Schedule Jobs die Nutzung zulässt.

Es gibt ein besseres Verfahren zum eintragen von Schedule Jobs - mit der Methode "Schedule.Create" bzw. "Schedule.Update" und im Code die Nutzung von "Script.Eval".

Dies gibt die derzeitige WebUI aber nicht her. Evtl. ließe sich mein Workaround per Cloud nutzen, ich finde aber eine Cloud-Nutzung für solche Zwecke unpassend.

Vielleicht wird Allterco die Konfiguration von Schedules offener gestalten. Spätestens dann wären die Schedules noch deutlich flexibler konfigurierbar - aber nicht für DAUs geeignet.

Man kann per Webseite eine solche Schedule Konfiguration sehr flexibel gestalten. Dies habe ich bereits in einem Projekt erprobt.

Ob ich für dich eine solche Webseite erstellen würde, hängt auch davon ab, was du wünschst.

Auch bin ich nicht sicher

Noch nicht ausgereift, aber prinzipiell funktionstüchtig:

let Status = {
  DigInp : null
};

Shelly.addEventHandler(
  function(e) {
    //print(JSON.stringify(e));
    let comp = e.info.component;
    if(comp===undefined) return;
    if (comp==="input:100") {
      print("Digital Input: ", e.info.state);
      Status.DigInp = e.info.state;
    }
  }
);

// Dort, wo bedingt geschaltet werden soll:
//  if(Status.DigInp) Shelly.call("switch.set", {id:0, on:true});

HTTPServer.registerEndpoint("switch_conditional",
  function(request) {
    if(Status.DigInp) Shelly.call("switch.set", {id:0, on:true});
  }
  
); 

Hier fehlt noch die response ...

Per http://<ip-address>/script/<script-id>/switch_conditional lässt sich die Funktion des Einschaltens, wenn dig. Input true ist, bereits nutzen.

Diesen URL könntest du in deine Schedule Jobs eintragen, ...

Vorteil:

Im nichtflüchtigen Speicher (NVS) finden seltener Schreibvorgänge statt - immer dann, wenn du einen Zeitplan änderst.

Edit:

Du kannst statt "switch_conditional" jeden sonstigen Text einsetzen, welcher dir zusagt.

Edit 1:

Beispiel-URL: "http://127.0.0.1/script/1/switch_conditional"

Nicht getestet, sollte logischerweise aber funktionieren, wenn ein solcher URL in einem Schedule Job konfiguriert werden kann.

TomyH

Mit Skriptstart lassen sich die Schedule Jobs enablen. ...

Wenn du den Schiebeschalter rechts hinter dem Skriptnamen aktivierst, wird das Skript mit dem Booten gestartet.

Ich versuche gerade, eine andere Variante, bleibe also bitte dran!

Deine Idee gefällt mir.

Kleiner Nachteil:

Jedes mal, wenn der dig. Input sich ändert, wird im NVS - hier den schedule jobs - geändert. Das ergibt relativ viele Änderungen.

Das lässt sich selbstverständlich vertreten.

In diesem Zusammenhang habe ich mir mal HTTPServer.registerEndpoint() angeschaut, ist aber noch schwach dokumentiert.

Evtl. ließe sich hiermit ein Workaround für eine nicht konfigurierbare Methode Script.Eval implementieren.

Bisher war ich noch nicht erfolgreich damit.