Beiträge von eiche

    Es ließ mir keine Ruhe. Hier die verbesserte Version des Skripts.

    Was habe ich verbessert?

    1. Das Skript ist besser strukturiert.
    2. Die Methode Script.Eval habe ich durch einen zweiten HTTP Endpoint ersetzt.
      Solange in den remote Geräten solche Endpoints verwendet werden - und kein Script.Eval - wird das Skript nicht abgebrochen, auch wenn der Endpoint Name nicht passen sollte.
    3. Die Protokollausgaben sind verständlicher und lassen den Ablauf leichter verfolgen.
    4. Der Ausgang, also dessen Id, kann per Variable out festgelegt werden.

    Was bleibt wie es war?

    Der Action URL in den Bewegungsmeldern, also nicht ändern! Endpoint Name lautet "on".
    http://<IP Adresse des Schalt-Shelly>/script/<Skript Id>/on?<Dauer in Sekunden>

    Was muss geändert werden?

    Der Action URL in den Geräten, die remote umschalten, also ändern! Endpoint Name lautet "toggle".

    http://<IP Adresse des Schalt-Shelly>/script/<Skript Id>/toggle

    Beide Informationen werden bei Skriptstart im Protokollfenster mit aktuellen Werten ausgegeben.

    Das gleiche Skript mit der nach ostfriese kleiner Änderung für die anwenderfreundliche Ausgabe nach Skriptstart.

    Dafür ist nichts an den anderen Geräten zu ändern.

    Neue Erkenntnis meinerseits.

    Nach Tests mit der Firmware 1.2.3 stellte ich fest, dass diese offensichtlich nach Erhalt der IP Adresse per DHCP diese Adresse nicht im nichtflüchtigen Konfigurationsspeicher ablegt.

    Somit findet man bei DHCP in der Antwort auf Methode Shelly.GetConfig keine IP Adresse, d.h. dass dort null steht.

    Ob dies auch in älteren Firmwareversionen so ist, kann ich derzeit nicht prüfen.

    Vielleicht werde ich gelegentlich das Skript so ändern, dass ein fehlerhafter URL das Skript nicht abbricht.

    Dazu muss ich statt der RPC Methode Script.Eval einen HTTP Endpoint verwenden, wie ich seit gerade eben feststellen konnte.

    Für die Motions habe ich im Skript einen solchen Endpoint verwendet.

    Der Unterschied:

    Methode Script.Eval: http://<IP Zieladresse>/rpc/script.eval?id=<script id>&code="<Funktionsaufruf>"

    HTTP Endpoint: http://<IP Zieladresse>/script/<script id>/<Endpointname> ...

    Wenn es mich packt, könnte ich das Skript entsprechend anpassen. Dann würde das Skript bei nicht existentem Endpointnamen selbstverständlich nicht reagieren aber auch nicht abgebrochen werden.

    Vielleicht wird ein Skript bei falschem Script.Eval Funktionsaufruf in einer späteren Firmware-Version nicht mehr abgebrochen - in Version 5.9.x vielleicht. ;)

    tomsta13

    Sorry, ich vergaß mitzuteilen, dass die alten URL nicht mehr passen. Du musst somit in allen hier beteiligten Geräten, bis auf Motions, den URL ändern.

    Er lautet jetzt am Ende ...&code="remoteButton()".

    Ich weiß derzeit nicht, wie ich einen solchen von extern verursachten Fehler (falscher URL) per Ausnahmebehandlung auffangen könnte. Vielleicht wäre dies mit dem Framework von @De kat möglich. Damit beschäftige ich mich aber jetzt nicht auch noch.

    Um die Wirkung eines solchen Fehlers deutlich zu verringern, kann man einen Schedule Job (Zeitplan) anlegen, der das Skript alle 5 Minuten (oder so) startet. Das gelingt aber nur per URL und nicht per Web UI, App oder Cloud.

    Zu deiner off topic Frage: ;)

    würde mich interessieren wofür du sie überall einsetzt beim WoMo

    Ich setze bisher im WoMo keinen einzigen Shelly ein. Den zusätzlichen Verbrauch scheue ich.

    Meine 12V Versorgung inkl. Gleichspannungswandler für

    • USB Ladeteil,
    • Notebooks,
    • FRITZ!Box 4020,
    • NAS (arbeitet zur Zeit nicht im WoMo)

    können wir per "Cockpit" Schalterchen inkl. Dioden-Logik und starken Solid State Relais ein- und ausschalten. Somit wird fast kein Strömchen für diese Geräte im ausgeschalteten Zustand verbraucht.

    Nur eine Stelle kann mich für den Einsatz eines Shelly + 12V Magnetventil NC reizen: Öffnen und Schließen des Grauwasserabflusses.

    Vermutlich lasse ich aber auch das sein.

    Aber einen kleinen Ama... Echo Input mit kleinem externen Bluetooth fähigen Lautsprecher führe ich mit und setze diesen gelegentlich zum hören von interessanten Radio-Programmen ein (fast ausschließlich WDR 5, die meisten anderen Programme sind imho großer Mist). Manchmal lasse ich darüber remote auch eine Lampe zu Hause schalten. :)

    tomsta13 und Andere ...

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

    Hier ist es, Erläuterungen unten:

    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 ...

    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.

    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.