Beiträge von eiche

Es bleiben folgende Fragen.

1. Warum sollen die beiden KVS Einträge entfernt werden? Es sollte genügen, sie zu überschreiben, bspw. mit den Werten 0.
2. Warum soll Skript 1 gestoppt werden?

Zu 1. Das kann auch per Schedule Job erfolgen. Ich versuche es mal.

http://<IP Adresse>/rpc/schedule.create?timespec="0 0 0 * * *"&calls=[{"method":"kvs.set","params":{"key":"EnergyConsumed","value":0}},{"method":"kvs.set","params":{"key":"EnergyReturned","value":0}}]

Die Methode "schedule.list" zeigt folgendes:

{
    "jobs": [
        {
            "id": 1,
            "enable": true,
            "timespec": "0 0 0 * * *",
            "calls": [
                {
                    "method": "kvs.set",
                    "params": {
                        "key": "EnergyConsumed",
                        "value": 0
                    }
                },
                {
                    "method": "kvs.set",
                    "params": {
                        "key": "EnergyReturned",
                        "value": 0
                    }
                }
            ]
        }
    ],
    "rev": 10
}

Hallo Marius alias Pit38

Da gibt es einiges zu klären.

1. Das Auflisten eines Schedule Jobs (Zeilen 4 bis 15) hat nichts mit einem Skript zu tun.
   Das ist ein solcher Job im JSON Format dargestellt. Ein Schedule Job, oder mehrere davon, lassen sich nicht in ein Skript einbauen, bzw. der JavaScript Interpreter kann dies nicht "verdauen".
   Der timespec ist übrigens unvollständig. Er braucht immer 6 Teile.
2. Eine Fallunterscheidung (scwitch, case, case, ..., default) ist nur dann zweckdienlich, wenn sich die Fälle (case Ausdruck: ...), also die Werte der Ausdrücke hinter den case unterscheiden. Vermutlich würde trotzdem diese Fallunterscheidung so abgearbeitet, wie du es erwartest.

Alles folgende ist ungetestet, sollte aber funktionieren.

Wenn ich dich richtig verstehe, genügt hierfür ein etwas komplexerer Schedule Job oder ein einfacher Schedule Job in Kombination mit einem Skript. Ich frage an dieser Stelle nicht nach dem Zweck deines Vorhabens.

Ein vermutlich für dein Vorhaben geeignetes Skript:

Shelly.call("script.stop", {id:1});
Shelly.call("kvs.delete", {key:"EnergyConsumed"});
Shelly.call("kvs.delete", {key:"EnergyReturned"});
Timer.set(5000, false, function() {Shelly.call("script.stop", {id:Shelly.getCurrentScriptId()});});

Dieses Skript stoppt Skript 1, entfernt die beiden Einträge mit den Keys "EnergyConsumed", "EnergyReturned" und stoppt sich selbst nach 5 Sekunden.

Ich habe die Wartezeit von 5 Sekunden eingebaut, um sicherzustellen, dass die ersten drei Anweisungen komplett ausgeführt werden. Man mag testen, ob dies immer auch ohne diese Wartezeit sichergestellt ist.

Angenommen, dieses obige Skript hat die Id 2. Dann kannst du den passenden Schedule Job wie folgt anlegen und die Zeitangabe später bspw. per Web UI ändern.

http://<IP Adresse>/rpc/schedule.create?timespec="0 0 0 * * *"&calls=[{"method":"script.start","params":{"id":2}}]

PM ist nicht erforderlich, den Plus 2 gibt es aber ausschließlich mit PM.

Zitat von Hellhound

welcher dem Shelly Plus i4 (der das Relais ersetzt) in der Lampe sagt welchen Ausgang er schalten soll?

Anders herum, ein i4 hat keine Relais, noch nicht einmal Ausgänge. An einen i4 werden Taster oder Schalter angeschlossen. i4 = input 4, d.h. er hat 4 Eingänge. Mit einem Plus 2(PM) kannst du zwei Stromkreise schalten, was in deinem Fall passen täte. Ein Plus 1 ist wenig geeignet, weil er nur einen Relais-Ausgang besitzt und einen Eingang. Willst du die beiden Stromkreise nicht auch unabhängig voneinander schalten können?

MartiS

Willst du deine Steuerung wirklich Cloud abhängig machen?

Siehe meine Signatur!

Es gibt eine Möglichkeit, die Messdaten lokal auf dem Shelly zu speichern - autark, per Skript.

Diese können bei Bedarf und Gelegenheit abgerufen oder per Copy & Paste übertragen werden. Das Ganze ohne Cloud.

Wer mehr mmöchte, dem kann ich im lokalen Netz einen Raspberry Pi empfehlen, auf dem Influx und Grafana laufen ... auch alles ohne diese abhängig machende Cloud.

Hellhound

Ich lese wiederholt von Shelly 2PM, weshalb ich einen aktuellen Shelly Plus 2PM vermute, also ein Gerät der zweiten Generation.

Mit einem solchen gelingt das, was du willst. Es ist allenfalls eine Frage des Aufwandes (evtl. im programmieren).

Da du eh Taster vorziehen willst, stehen hierfür Ereignisse wie push, long push, double push und triple push zur Verfügung - vielleicht nicht auf einem Plus 2PM, aber jedenfalls auf einem Shelly i4.

Den i4 kannst du zum reinen Steuern eines Plus 2PM an der Lampe verwenden. Das muss aber nicht sein, wenn genügend Leitungen zur Lampe führen und der Plus 2PM die von dir gewünschten Ereignisse zur Verfügung stellt.

An Hand solcher Ereignisse kannst du Webhooks (=Actions) einrichten, die das Gewünschte veranlassen.

Per Skript auf einem Plus 2PM gelingt es in jedem Fall.

Schau mal hier:

Das RPC Konzept ist überzeugend. Du kannst dir die RPC Antworten leicht per Browser ansehen.

http://<IP Adresse>/rpc/<Methode>?<Parameter, falls erforderlich>&<weiterer Parameter>

Auf Windows sind Firefox oder Edge zu empfehlen, weil diese die Antworten übersichtlich strukturiert darstellen.

Edit: Sorry, der zielführende Link ist dieser

https://shelly-api-docs.shelly.cloud/gen2/Component…shellygetstatus

konkret: http://<IP Adresse>/rpc/switch.getstatus?id=0

Die Antwort liegt im JSON Format vor. Nach der Konvertierung in ein Objerkt "obj" gelingt der Zugriff per obj.apower. Auch stehen weitere Daten wie obj.voltage, obj.current ... zur Verfügung.

Edit:

Du kannst die gewünschten Daten auch vom Shelly Plus Plug S so senden lassen, wie es dein "Arduino"-System gut verarbeiten kann. Dies gelingt am flexibelsten per Shelly Script.

yppiks

Du willst ja einen Shelly Plus 2PM dazu bringen, das manuelle Schalten per doppeltem "Schalterdruck" (?) nachzubilden. Kein Taster?

Da es keinen URL gibt, der einen Schaltimpuls verzögert, also bspw. in 1 s auslöst, sehe ich ausschließlich die Lösung per Skript.

Du willst ja bspw. einen 0.5s langen Impuls, gefolgt von einem weiteren 0.5s langen Impuls per Plus 2PM schalten lassen.

Dies gelingt per Timer.set(...) in einem Skript.

Willst du darüber mehr wissen?

Edit:

Entscheidend ist das Verhalten des Plus 2PM. Welches Bedienelement dieses auslöst ist letztlich unwesentlich, solange dieses die entscheidenden Befehle in einem zeitlichen Abstand per URL sendet.

Edit 2:

Ein solches Skript kann auf dem Plus 2PM laufen und einen sog. HTTPServer Endpoint zur Verfügung stellen. Dieser empfängt eine Nachricht und generiert daraufhin die gewünschten Schaltvorgänge.

Diesen URL kann ein Wall Display (vermutlich, ich habe kein solches) oder ein Shelly i4 oder ein Shelly der ersten Generation oder ... senden.

1. Es gibt kein "MQTT Netzwerk", aber einen MQTT Broker.
2. Hast du mal ein MQTT Tool zwecks beobachten der Nachrichten eingesetzt? MQTT fx oder MQTT Explorer ...
3. Woran siehst du, dass ein Shelly keine MQTT Nachrichten sendet bzw. empfängt?

Die Portnummer ist standardmäßig 1883.

Hm, das könnte mich auch interessieren.

Hundehütte fehlt noch.

Da schließt sich eine Frage meinerseits an:

Ich habe eine Kombinationsheizung von Truma, analog gesteuert per Drehschalter und irgendwie analogem Einstellring. Dies ist von uns sehr feinfühlig einzustellen, also ohne Sollwert, welcher digital verarbeitet werden kann. Falls ein Foto erforderlich sein sollte, kann ich dies beifügen. Das Prinzip sollte aber klar sein.

Ich habe bisher nicht eingegriffen und auch nicht versucht, hinter den Einsteller zu schauen.

Kennt hier jemand eine einfache Möglichkeit der digitalen Regelung per Shelly-Hardware, also Anschlussplan?

Truma Heizung Combi Gas

Zitat von ostfriese

66er Ist übrigens passiert, als ich an "deinem" Projekt gearbeitet habe.

Darf ich darüber mehr erfahren?

hust ...

Es war eher nur eine kleine Idee in der Ratlosigkeitswüste. Vorschlag ist leicht überhöht.

Ein Test mit einem laufenden, allerdings weniger sabotierendem Skript gelang jedenfalls.

Am zusätzlichen Shelly schließt du den Doppelschalter an. Ist es kein Doppeltaster?

Dieser Shelly braucht selbstverständlich zwei Eingänge. Falls du dafür einen Shelly kaufen willst, empfehle ich den i4.

Auf diesem Shelly legst du für jede mögliche Schalterkombination eine Action (=Webhook) an und trägst für alle Rollladen/Jalousien Shelly, die du mit diesen Schaltern steuern willst, je einen URL ein. Wie der jeweilige URL lauten muss, kannst du der Dokumentation entnehmen.

Noch ein Tipp:

Bevor du einen URL in eine Action einbaust, kannst/solltest du diesen per Browser-Adresszeile testen.

ostfriese

Hast du mal die Methode Script.SetConfig versucht?

Falls die Firmware eine Chance hat, darauf zu reagieren, wird mit folgendem URL der automatische Start verhindert.

http://<ip address>/rpc/script.setconfig?id=<script id>&config={"enable":false}

Danach reboot ...

Teste doch einfach die Lösung von thgoebel in #2!

Sorge zuerst dafür, dass der AP des Shelly aktiv ist und gib diesem ein Passwort!

Deaktiviere dann die Cloud und am besten entferne den Shelly aus dem WLAN!

Dann führe den Funktionstest durch.

Du kannst dann immer noch den Shelly über dessen Access Point erreichen.

ToLa62

Was hast du denn wildes in deinem Skriptexperiment versucht?

Zitat von ToLa62

oder wenigstens im lokalen Netz ansprechen können

Also hast du dessen Access Point deaktiviert.

Für zukünftige Experimente/Projekte:

Lasse den AP des Shelly zusätzlich aktiv und gib ihm ein Passwort!

Dann wirst du ihn per IP Adresse 192.168.33.1 ansprechen können, nachdem du dein Endgerät mit seinem WLAN gekoppelt hast.

Wenn alle Versuche fehlschlugen, ist der Shelly vielleicht defekt.

ToLa62

Dein Skriptskelett in #1 startet sich nicht selbst. Dies wäre ohnehin paradox. Ein laufendes Skript sich selbst starten zu lassen, obwohl es schon läuft?

Im Ernst:

In einem Shelly Skript gibt es keine Endlosschleife. Ein solches Skript sollte, wenn es etwas zielführendes tun soll, Ereignis gesteuert arbeiten.

Du kannst etwas ähnliches nachbilden per Timer, der eine Funktion periodisch aufruft.

Dafür gibt es Methoden.

Zum Factory Reset sollte diese Methode führen: Shelly.FactoryReset

Solange der Plus 1 bzw. Shelly ab der zweiten Generation erreichbar ist:

http://<IP Adresse>/rpc/shelly.factoryreset

Ich habe es nicht getestet, rechne aber wegen der eindeutigen Dokumentation damit, dass dies funktioniert.

Edit:

Interessant wäre ein Versuch, dies per Skript zu realisieren:

Folgende Anweisung sollte hierfür genügen.

Shelly.call("Shelly.FactoryReset", {});

Ich habe mir etwas tiefergehend die Webhooks (=Actions) angesehen.

Prinzipiell ist es möglich, das Skript auf dem Plus 2PM (s. #11) durch 5 Webhooks zu ersetzen, aber ...

1. Der Pflegeaufwand bei einer Änderung ist in den Webhooks höher und damit fehleranfälliger.
2. Die Dokumentation zu den Tokens (${x.y}) erscheint mir nicht zufriedenstellend oder deren Konzept ist nicht sehr systematisch/ausgereift.
   Das RPC Konzept ist erheblich ausgereifter und kann leicht in einem Skript genutzt werden.

Beispiel zu 2.

Wenn ich einem Endpoint eine strukturierte Information übermitteln will, in welcher der Device Name enthalten ist, so kann dieser leicht per RPC Aufruf in einem Skript geholt werden. Ich habe viele Experimente per Token in einem Webhook durchgeführt und hatte keinen Erfolg, wohl hauptsächlich, weil es hierzu an Dokumentation oder durchgreifendem Konzept fehlt.

Fazit: Wenn ausgefeilte, nicht vorgefertigte Pfade beschritten werden sollen, sind Skripte den Webhooks deutlich überlegen. Dann stoßen Webhooks bereits früh an ihre Grenzen.

Falls per Methode Webhook.Create oder Webhook.Update doch noch ausgefeiltere Dinge möglich sein sollten, werde ich gerne meine Aussage relativieren.