Beiträge von eiche

Nicht Retriggerung funzt wohl noch nicht. Ich untersuche ...

Ich machte einen Anfängerfehler. Das Skript wird oben von mir korrigiert.

Nun aber ...

tomsta13 und Andere ...

Ich glaube, dass ich das Skript funktionstüchtig fertig habe.

Hier ist es, Erläuterungen unten:

// Created by Gerhard Eichelsdörfer alias eiche - 2024-03-13

let Retrigger = true, // Set to false if you don't want the motion to retrigger!
MotionName = "motion",
RemoteName = "remote",
on = null, // output status
th = null, // timer handle
src = null; // source of switching

function send_response(response, body) {
  response.code = 200;
  response.body = body;
  response.send();
}

function switchSet(state) {
  Shelly.call("Switch.set", {id:0, on:state},
    function(result, errcode, errmsg) {
      let msg = "switchSet(" + state + "): ";
      if(errcode!==0) msg += "error " + errcode + ", " + errmsg;
      else msg += state ? "is on" : "is off";
      print(msg);
    }
  );
}

function startTimer(dur) {
  Timer.clear(th);
  if(dur>0) th = Timer.set(Math.floor(1000*dur), false, function () {switchSet(false);});
}

HTTPServer.registerEndpoint('on',
  function (request, response) {
    send_response(response, "OK");
    let dur = 0;
    if(request.query.length > 0) dur = JSON.parse(request.query);
    if(!on) src = MotionName;
    if(!isNaN(dur) && dur>0 && (!on || (Retrigger && src===MotionName))) startTimer(dur);
    if(!on) {
      src = MotionName;
      switchSet(true);
    }
  }
);

Shelly.addEventHandler(function(e) {
  //print(JSON.stringify(e));
  if(e.info.event==="toggle") {
    on = e.info.state;
    let st = Shelly.getComponentStatus("switch:0");
    //print(JSON.stringify(st));
    if(st.source!=="loopback") src = st.source;
    if (e.component==="input:0" || st.source==="button" || st.source==="WS_in" || st.source==="SHC" || src===RemoteName) {
      print("source: ", src);
      Timer.clear(th);
    }
  }
});

// from a remote toggle call, e.g. from an i4.
function remoteButton() {
  let err = "error in remoteButton:";
  let st = Shelly.getComponentStatus("switch:0");
  if(!st.output || src===MotionName) Shelly.call("Switch.Set", {id:0, on:true},
    function (result, errcode, errmsg, err) {
      if(errcode!==0) print(err, errcode, ", ", errmsg);
      else src = RemoteName;
    }, err
  );
  else Shelly.call("Switch.Toggle", {id:0},
    function (result, errcode, errmsg, err) {
      if(errcode!==0) print(err, errcode, ", ", errmsg);
      else src = RemoteName;
    }, err
  );
}

//Do some user friendly printout
function messages() {
  let ipAddress = Shelly.getComponentConfig("wifi").sta.ip;
  if(ipAddress===null) ipAddress = '<IP address of your switching Shelly>';
  let myId = Shelly.getCurrentScriptId();
  print('The action URL of your motion is: http://' + ipAddress + '/script/' + myId + '/on?<duration in seconds>');
  print('When switching via remote command, e.g. Shelly i4, the URL for the remote action is:');
  print('http://' + ipAddress + '/rpc/script.eval?id=' + myId + '&code="remoteButton()"');
}

messages();

let info = Shelly.getComponentStatus("switch:0");
//print(JSON.stringify(info));
src = info.source;
on = info.output;

Ich testete es mit einem bereitliegenden Shelly Plus Plug S. Dieser Shelly ähnelt einem Shelly 1PM Mini (Gen 3), da beide u.a. die entnommene Leistung messen. Somit sollte dieses Skript auch auf dem Mini stabil laufen und sich nichts Irritierendes ereignen. Es könnte noch verbessert werden, indem ich den HTTP Endpoint für weitere Parameter ausbaue. Ich bin aber nun froh, dass es so funktioniert.

Es berücksichtigt verschiedene Quellen des Schaltens - Schalter/Taster am Eingang, den Button am Plus Plug S, das Klick Button Symbol in der Web UI, per Cloud und damit auch per Sprachassistent sowie insbesondere das Schalten per Shelly i4 ...

Entscheidend ist die Unterscheidung zwischen Bewegungsmelder(Motion)-Aktionen und anderen Aktionen.

Alle Quellen, die den Verbraucher (Lampe) für eine gewisse Dauer einschalten (wie Motions), müssen folgenden URL nutzen:

http://<IP address of your switching Shelly>/script/<script id>/on?<duration in seconds>

Alle Quellen ohne eine solche Dauer müssen diesen URL verwenden:

http://<IP address of your switching Shelly>/rpc/script.eval?id=<script id>&code="remoteButton()"

Beide URL werden mit dem Skriptstart im Protokollfenster ausgegeben, um den Anwender ein wenig zu unterstützen - eine Idee von ostfriese.

Die Funktion zu letzterem habe ich "remoteButton()" genannt, weil das Skript deren Aufruf wie einen Umschalte-Button behandelt, d.h. mit jedem Auftrag an diese Funktion wird ein Umschalteauftrag abgearbeitet.

Ist eine Dauer (hier Timer) aktiv und remoteButton() wird aufgerufen, dann wird diese Dauer gelöscht, wodurch der Verbraucher eingeschaltet bleibt, bis remoteButton() erneut aufgerufen wird. oder mit einer anderen, nicht Dauer behafteter Quelle ausgeschaltet wird. Somit ist der Anwender sehr flexibel in der Nutzung einer bspw. manuell bedienbarer Schaltquelle - auch ein Shelly Button 1 ist dazu geeignet.

Dauer behaftetes Triggern ist per Variable "Retrigger = true;" auf Retriggerung eingestellt, d.h. die Dauer beginnt mit jedem Dauer behafteten URL von vorne. Will man das nicht, setzt man schlicht Retrigger auf false.

Einige print() Aufrufe sind enthalten, mache auskommentiert und wenige aktiv. So lässt sich eine evtl. erforderliche Fehlersuche leichter durchführen.

Ich glaube aber, dass dieses Skript fehlerfrei arbeitet.

Für weitere Fragen stehe ich zur Verfügung. Viel Freude damit!

Edit:

Der Vollständigkeit wegen sei noch einmal erwähnt, dass die Konfigurationsabfrage in der Firmware 1.2.3 bei Nutzung von DHCP keine IP-Adresse liefert, sondern nur einen null Wert. Dies beeinträchtigt aber nicht die Funktion des Skripts.

tomsta13

Guten Morgen.

Ich nutze jetzt einen Shelly Plus Plug S im Wohnmobil, um damit zu experimentieren. Der wird sich bzgl. Schalten so verhalten wie ein Mini.

Motion und i4 kann ich per URL im Browser simulieren.

Erste Erkenntnis:

Da ich hier, wo das WoMo steht, keine statische IP Adresse vergeben kann, nutzt der Shelly DHCP. Ich sehe mir dessen Konfiguration per .../rpc/shelly.getconfig an. Hier zeigt mir die Antwort, dass der Shelly (bei DHCP und Firmware 1.2.3) in wifi.sta null liefert. Ob dies an der aktuellen Firmware oder DHCP liegt, weiß ich nicht. Jedenfalls ist in seiner gesamten langen Antwort seine IP Adresse nicht zu finden. Das brauchen wir für eine richtige Funktion des Skripts nicht. So wissen wir aber, dass der Wert null für die IP Adresse bei DHCP derzeit normal und kein Fehler im Skript ist.

Ich werde nun weiter am Skript arbeiten ...

Vielleicht kann eine partielle Entmagnetisierung helfen, aber seeehr vorsichtig.

Ich mache jetzt eine Pause, Hirn dampft.

Interessante Idee, es genügt aber nicht.

Am Schaltaktor(Mini) von tomsta13 ist, anders als beim TE, kein Schalter angeschlossen. Stattdessen lässt er per i4-Nachricht schalten.

Wenn der Motion per Nachricht an den Schaltaktor die Lampe für eine gewisse Dauer einschalten lässt, dann muss die Dauer des Eingeschaltetbleibens per Druck auf einen Taster am i4 deaktiviert werden, damit die Lampe an bleibt.

Ist die Lampe bereits an, darf die Nachricht des Motion sie nicht nach Ablauf der übertragenen Dauer ausschalten.

Sorry, ich hänge gerade tief im Skriptablauf und kann mich deshalb nicht zugleich mit der Möglichkeit per Actions beschäftigen.

Da ich selbst das Skript, aber mit Schalter am Schaltaktor Shelly Plus 1, nutze und ich vor dem Skript erfolglos versuchte diese Funktionalität per Actions zu implementieren, glaube ich nicht an eine skriptlose Möglichkeit.

Ich bin aber selbstverständlich offen.

Das Problem liegt hier darin, dass der Schaltaktor an Hand einer immer gleichen Nachricht vom i4 erkennen muss, ob er ein- oder ausschalten oder einfach nur die Dauer deaktivieren muss.

Ich habe etwas gefunden.

switchToggle() ist Mist. Damit schaltet der i4 sofort die Lampe aus, wenn sie zuvor per Motion eingeschaltet wurde.

Ich wählte toggle, weil du (vermutlich) nur per (kurzem) Tastendruck per i4 die Lampe schalten willst, also von aus nach ein bzw. von ein nach aus.

Das ist in diesem Szenario kontraproduktiv, weil der Motion ja bereits eingeschaltet haben kann.

Am einfachsten gelingt es, wenn du zwei Taster dafür reservierst, einen zum Ein- und einen zum Ausschalten.

Ich will noch prüfen, ob das Ziel mit einem einzigen Taster erreichbar ist.

Zitat von tomsta13

der i4 reagiert mit der neuen url nicht mehr:Angabe hinter i4 in #26

Der Mini muss reagieren.

Läuft das Skript auf dem Mini?

Mit rpc/switch.toggle?id=0 gelingt das Gewünschte nicht, weil dies ein Ereignis auslöst, in welchem nicht unterscheidbar ist, ob per Motion oder per i4 geschaltet wurde.

Im ursprünglichen Skript (ohne i4) mit Schalter am Eingang gelang dies problemlos.

Die Angabe hinter i4: in #26 muss so im i4 hinterlegt werden, etwas anderes führt nur zur Nichtfunktion.

Vergiss erst einmal diese IP Adresse. Diese Ausgaben unterstützen nur den Anwender mit den Anzeigen für zwei entfernte Sender der Schaltnachricht.

Die Funktionalität des Skripts ist davon unberührt.

Ich habe analysiert und nachgedacht.

Es ist nicht möglich, per HTTP GET mit RPC im Mini die beiden Quellen, welche das Schalten getriggert haben zu unterscheiden - also den Motion vom i4 zu unterscheiden.

Solches gelänge mit einem weiteren Parameter im Funktionsaufruf oder einem zusätzlichen HTTP Endpoint. So wie das Skript derzeit gestaltet ist, ist es zügig zielführend, zwei unterschiedliche RPC Aufrufe zu verwenden.

Das muss so gelingen, wie ich es bereits beschrieb.

Motion: http://<IP Adresse Mini>/script/<Skript Id>/on?<Dauer>, bspw. http://<IP Adrresse Mini>/script/1/on?180

i4: http://<IP Adresse Mini>/rpc/script.eval?id=<Skript Id>&code="toggleSwitch()", bspw. http://<IP Adresse Mini>/rpc/script.eval?id=1&code="toggleSwitch()"

Der Action URL ersetzt quasi den Schalter an einem Eingang.

Lol, jetzt fällt mir erst die starke Namensähnlichkeit auf - Shelly Script und Shell Script. Nur ein y macht den Unterschied.

Vermutlich kennt die KI kein Shelly Script.

Das bringt nichts, weil diese Variablen eine ganz andere Bedeutung/Verwendung haben.

Btw, das Skript in #18 ist unvollständig, das Bild dazu zeigt aber die letzten Skriptzeilen.

Merkwürdig, ich testete das Skript (für die Ausgaben) an einem Plus Plug S und dort bekomme ich mit jedem Skriptstart die richtige IP Adresse.

Ich werde weiter testen ...

Du kannst versuchsweise in der letzten Zeile mal den Wert 2000 auf 5000 ändern.

Zitat von tomsta13

script in #12 kopiert und das alte ersetzt im 1pm mini - wieder keine ip-Ausgabe…?

Ok, ich schaue mal, woran das liegen mag. Das Skript sollte trotzdem funktionieren.

Ersetze erst einmal "null" durch die Mini IP Adresse!

Verwende also die beiden Ausgaben für den Motion und für den i4, wobei du "null" durch die IP Adresse des Mini ersetzen musst!!

Oh ja ... Moment. Ich habe das Skript in #12 ein wenig ergäzt.

Nun sollte die richtige IP Adresse ausgegeben werden. Du hast sie aber strukturell richtig eingebaut.

Diese Ausgabe ist für die Funktionalität unerheblich.

.../rpc/switch.toggle?id=0 geht ja selbstverständlich auch. Das hatte ich nicht im Blick.

Allerdings ist das Skript so nicht darauf eingestellt. Das ist zwar möglich, dafür müsste ich aber die Event Informationen genauer analysieren und verwenden.

Stelle also auf dem i4 unter ... Action den folgenden URL ein:

http://<IP Adresse des Mini>/rpc/script.eval?id=1&code="ToggleSwitch()"

1. Ich kann die App/Cloud dafür nicht empfehlen.
   Nimm stattdessen einen Web Browser mit der IP Adresse des Mini bzw. des Motion bzw. des i4.
2. Arbeitet das Skript (auf dem Mini!) durch oder wird es mit einer Fehlermeldung abgebrochen?
3. Hast du gemäß der Skriptausgaben nach dem Skriptstart die Actions sowohl auf dem Motion als auch auf dem i4 eingerichtet?
   Nach meiner Skripterweiterung muss dies noch auf dem i4 erfolgen.
   Drei Zeilen werden unmittelbar nach Skriptstart ausgegeben.
   Die erste Zeile gilt dem Motion, die zweite ist nur Text.
   Die dritte Zeile enthält den URL für den i4 - dem entsprechenden Eingang/Button zugeordnet.

Edit: Lösche das Protokoll !!! Einen key sollte man nicht veröffentlichen.

Das "Protokoll" ist wohl die Ausgabe auf einen RPC Aufruf wie Shelly.GetStatus.

Das ist ein Unix/Linux Shell Script und als Shelly Skript total ungeeignet.

So etwas wäre vielleicht auf einem Raspberry Pi nutzbar, wenn dieser den Rollladen-Shelly steuern soll, was nicht empfehlenswert ist.

Aber alle Achtung, das sieht für eine KI nicht schlecht aus.

Zitat von ToLa62

Mal angenommen, ich würde diesen Weg gehen. Ich hätte trotzdem wieder eine Inter-Shelly-Kommunikation.
Die ließe sich (nach meinen naiven Annahmen) nur vermeiden, wenn ich eine Drahtverbindung zwischen Sensor und Add-On auf dem Shelly herstellen würde.

Die Kommunikation zwischen einem Nicht H&T Shelly und dem Schalt-Shelly funktionieren nach meinen Erfahrungen sehr zuverlässig.

Ich finde schlicht keine verständliche Ursache für das Nichtsenden des H&T im kurzen Zeitintervall.

Auch kann ich derzeit wegen Abwesenheit meinen einzigen Plus H&T dbzgl. nicht testen.

Die Nutzung der Cloud ist jedenfalls eingeschränkter als eine lokale Nutzung, bei welcher ausschließlich die beteiligten Shelly miteinander kommunizieren.

Zitat von ToLa62

13:55-14:25 -> ob tatsächlich das T-Kriterium weggelassen wird, kann ich nicht sicherstellen, da ich im GUI für die Action zwingend eine Überprüfung der Temperatur drin haben muss,

Das sehe ich anders. Wenn der H&T alle 5 Minuten seine Temperatur per Aufruf der Skriptfunktion mitteilen kann, genügt das völlig. Ob dies auf einem H&T als Action konfiguriert werden kann, weiß ich derzeit nicht. Mit einem messenden Plus 1 gelänge dies per Skript leicht. Der Action URL müsste sinngemäß wie folgt lauten.

http://192.168.178.16/rpc/script.eval?id=<Skript Id>&code="htTest(<aktuelle Temperatur>)"

Selbstverständlich muss dann die Skriptfunktion einen Parameter importieren, bspw. so:

function htTest(temp) {
    print("htTest wurde aufgerufen. Temperatur: ", temp);
}

In einem Mess-Shelly Plus 1 mit AddOn werden die Temperaturen in ca. 1 minütigen Abständen (nicht ganz regelmäßig) erfasst und können bspw. per Skript an den Schalt-Shelly gesendet werden. Dies täte sicherer funktionieren als mit einem H&T, der nicht skriptfähig ist. Die Zeitintervalle können auf dem einen oder dem anderen Plus 1 in ein Skript konfiguriert werden. Auch Schedule Jobs könnten eingesetzt werden.

Die Actions sind für Leute, die per Klicks, Auswahlen und wenigen Eingaben etwas erreichen wollen - und möglichst keine Wunder erwarten sollten.

Mit einem Skript ist man erheblich flexibler und kann viel mehr erreichen als mit diesen Actions. Ich nehme auch eine Action, wenn dies bereits genügt, aber in vielen meiner Einsatzzwecke genügen solche Actions nicht.

Das angepasste Skript.

Es enthält zusätzlich die Funktion toggleSwitch() für einen entfernten Auftrag, bspw. von einem i4.

let on = null; // output status
let th = null; // timer handle
let src = null; // source of switching

function send_response(response, body) {
    response.code = 200;
    response.body = body;
    response.send();
}

HTTPServer.registerEndpoint('on',
  function (request, response) {
    send_response(response, "OK");
    if (on!==true) {
      src = 'motion';
      Shelly.call("Switch.set", {'id': 0, 'on': true});
      if (request.query.length > 0) {
        let dur = JSON.parse(request.query);
        // print(dur);
        if(!isNaN(dur) && dur>0) {
          th = Timer.set(Math.floor(1000*dur), false,
            function () {
              Shelly.call("Switch.set", {id: 0, on: false});
            }
          );
        }
      }
    }
  }
);

Shelly.addEventHandler(function(e) {
  on = e.info.state;
  if (e.component==="input:0" || src!=='motion') {
    Timer.clear(th);
  }
});

// Für einen entfernten toggle Aufruf, bspw. von einem i4.
function toggleSwitch() {
  Shelly.call("Switch.Toggle", {id:0},
    function (result, errcode, errmsg) {
      if(errcode!==0) print("error in toggleSwitch:", errcode, ", ", errmsg);
      else src = 'remote';
    }
}

//Do some user friendly printout
function messages() {
  let ipAddress = Shelly.getComponentConfig("wifi").sta.ip;
  let myId = Shelly.getCurrentScriptId();
  print('Your motion url is: http://' + ipAddress + '/script/' + myId + '/on?<duration in seconds>');
  print('When switching via remote command the url at the remote action is:');
  print('http://' + ipAddress + '/rpc/script.eval?id=' + myId + '&code="toggleSwitch()"');
}

Timer.set(2000, false, messages);

Ich kann es gegenwärtig nicht testen, könnte aber funktionieren. Das Skript reagiert nun sowohl auf einen Schalter am Eingang 0 als auch auf einen Fernaufruf vom i4.

Nach dem Skriptstart erhältst du im Protokollfenster zwei Ausgaben.

1. Den URL für den motion.
2. Den URL für den i4

Teile bitte den Erfolg bzw. Nichterfolg mit!

Du kannst den Skriptinhalt (zwecks Kontrolle) in einen Code-Abschnitt (</>) statt als Abbildung einfügen. Dann ist er

1. besser lesbar,
2. scrollbar,
3. kopierbar.

Zitat von seba28

Der mini ist zusätzlich mit einem Schalter verbunden, um das Licht manuell einschalten zu können.

So in #1

Zitat von tomsta13

Tastendruck auf shellyi4 —> Befehl an 1pm mini —> Licht ein

Das widerspricht der Info in #1 und war mir bisher nicht bekannt.

Dafür muss das Skript ein wenig geändert werden.

Ich werde es mit der Änderung nachreichen.

Ups, hast du zwei Konten? Oder hast du dich später eingeklinkt?

Sorry horkatz , aber das versenden von Nachrichten über Internet ist in Notsituationen keine wirklich gute Idee.

Als optionale Ergänzung Ok.