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.
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. 
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.
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.
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
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.
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.
Was hast du denn wildes in deinem Skriptexperiment versucht? 
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.
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 ...
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.
Btw, da gibt es einen kleinen verräterischen Fehler in der Dokumentation - im ersten Absatz. Vielleicht finde ich noch weitere.
A revision number is maintained which is incremented on every update of the schedules.
Vermutlich wurde hier aus der Doku zu Schedule kopiert und unter Webhook eingefügt. Richtig sollte es lauten:
A revision number is maintained which is incremented on every update of the webhooks.
Sehr interessant. Mit solchen Webhooks habe ich mich noch nicht in Tiefe beschäftigt.
Insbesondere die "condition" Komponente ist beachtenswert. Ich werde bei Gelegenheit damit experimentieren. Vielleicht kann so etwas das eine oder andere kurze Skript ersetzen.
Und per Komponente "enable" lässt sich ein solcher Webhook bspw. per Schedule Job sperren/freigeben. Das ist eine vielversprechende Kombination.
Es ist gut möglich, dass hiermit dein Anliegen implementierbar ist.
Diese Webhooks, bspw. per Web UI, einzurichten, ist allerdings auch etwas gewöhnungsbedürftig. Soll heißen, wer brauchbar skripten kann, kommt damit evtl. zügiger zum Ziel - neben der höheren Flexibilität per Skripten. So gesehen bilden die Webhooks eine Teilmenge von per Skript möglichen Implementationen ab.
Nun schließlich die fast komplette Skriptlösung. Sie ist nur deshalb fast komplett, weil ich weit weg von den Tasten bin und die im EventHandler eintreffenden Events nicht prüfen kann. Dies ist erforderlich, um daraus die Filterbedingung im EventHandler handleButton (s. Skript) zu komplettieren. Das folgende Skript für den i4 ist somit ungetestet, stellt aber die wichtigsten Dinge bereits zur Verfügung. Dabei habe ich versucht, das Skript kurz und einigermaßen verständlich zu gestalten.
let Destination = "172.16.3.66", // IP address of the cover controller
ButtonId = 0,
longPushURL = "http://" + Destination + "/rpc/cover.close?id=0",
shortPushURL = [ // Datenfeld aus zwei URL, Zugriff per Index 0 oder 1
"http://" + Destination + "/rpc/cover.open?id=0",
"http://" + Destination + "/rpc/cover.stop?id=0"
],
Sel = 0; // selected shortPushURL Index
function receiveStatusCover_0(request) {
if(request.method==="GET" && request.query!==undefined) {
print(request.query);
Sel = request.query==="stopped" || request.query==="closed" ? 0 : 1; // für short push vorselektieren
}
}
HTTPServer.registerEndpoint("Cover_0", receiveStatusCover_0);
function handleButton(event) {
// print(JSON.stringify(event)); // zwecks Analyse aller eintreffenden Events
if( // das passende Event filtern, vorfiltern per component "input:<ButtonId>"
event.component==="input:" + ButtonId
// && // passende Filter hinzufügen
) {
print(JSON.stringify(event)) // zwecks Analyse der hier zu verarbeitenden Events wie push und long push
// Sobald klar ist, welche Infos zur Weiterverarbeitung zu nutzen sind, die folgenden Anweisungen passend ergänzen und Kommentarsymbole (//) entfernen!
let Url;
// if(<long push selektieren>) Url = longPushURL;
// else Url = shortPushURL[Sel];
// Shelly.call("http.get", {url:Url}); // für das Verarbeiten des Tastendrucks
}
}
Shelly.addEventHandler(handleButton);Viel mehr kann ich aus der Ferne leider nicht tun.
Das Skript auf dem Plus 2PM bleibt so wie in #11.
Hinweis:
Das i4 Skript lässt sich auf alle Eingänge, also 4 Tasten, erweitern. Hierfür sind 3 weitere HTTP Endpoints, eine etwas komplexere Datenstruktur (in den ersten Skriptzeilen) und eine Erweiterung des EventHandlers erforderlich. Je durchdachter die Datenstruktur gestaltet ist, desto kürzer kann der Ablaufcode gehalten werden - bei zugleich besserer Wartbarkeit. Wenn die Skripte auf den Plus 2PM etwas flexibler gestaltet würde, d.h. bspw. dem Status noch die Quelle beigefügt, braucht man im i4 Skript keinen zusätzlichen HTTP Endpoint. Vielleicht werde ich eine solche Lösung gelegentlich aufzeigen.
Fortsetzung zu #10
Das Skript auf dem i4 soll eine Status-Nachricht vom Plus 2PM empfangen. Hierfür ist am besten ein HTTP Endpoint (genauer HTTPServer Endpoint) geeignet.
Das Skript auf dem i4:
function receiveStatusCover_0(request) {
if(request.method==="GET" && request.query!==undefined) {
print(request.query);
}
}
HTTPServer.registerEndpoint("Cover_0", receiveStatusCover_0);Die HTTPServer Endpoint Funktion habe ich receiveStatusCover_0 genannt. Dieser Name kann auch anders gestaltet werden, bspw. statusBad1Rollladen. So oder so muss diese Funktion als Endpoint registriert werden, was per Aufruf von HTTPServer.registerEndpoint geschieht. Die Funktion gibt zunächst nur den empfangenen Wert aus.
Nun muss noch der Plus 2PM seinen Cover:0 Status an den i4 übermitteln. Hierfür ist die Methode "HTTP.GET" geeignet, die als Parameter den URL braucht, also die IP Zieladresse (des i4) und zusätzliches für den Endpoint des Plus 2PM.
Ich nehme im weiteren Verlauf die folgenden IP Adressen an, die für deine Zwecke anzupassen sind.
i4: 172.16.3.68
Plus 2PM: 172.16.3.66
Beide Skripte mögen bspw. die Id 1 besitzen. Deren Id lassen sich leicht per Browser herausfinden: http://<IP Adresse>/rpc/script.list
Dies listet alle auf dem Shelly gespeicherten Skripte auf - id, name, enable, running. Die Id ist entscheidend.
Das Skript auf dem Plus 2PM:
function sendStatus(status) {
if(status.component==="cover:0"
&& status.delta!==undefined
&& status.delta.state!==undefined) {
print(status.delta.state);
Shelly.call("http.get", {url:"http://172.16.3.68/script/1/Cover_0?" + status.delta.state});
}
}
Shelly.addStatusHandler(sendStatus);Der URL setzt sich wie folgt zusammen.
Das Protokoll (http://), die IP Zieladresse (des i4), "/script/", die Skript Id des i4, Slash, Name des Endpoints (Cover_0), Fragezeichen gefolgt vom Request (geänderter Status der Component "cover:0")
Für die Funktion, hier noch ein Test, müssen beide Skripte laufen.
Wenn du per Plus 2PM den Rollladen steuerst, wirst du in beiden Konsolenfenstern die gleichen Ausgaben vorfinden. Die beiden jeweils gleichen Ausgaben erfolgen auf dem i4 ca. 2s nach denen auf dem Plus 2PM. Der i4 erhält also zeitnah die Mitteilungen über die Statusänderungen des Rollladens am Plus 2PM - und kann diese für die Zielfunktionalität verarbeiten. Letzteres kommt noch in einer Fortsetzung. Da die Verarbeitung des empfangenen Status auf einen nächsten kurzen Tastendruck vorzubereiten hat, sollte eine Verzögerung von ca. 2s kein Problem darstellen.
Hinweis: Diese Skripte habe ich so kurz wie möglich gehalten. Man kann weitere Dinge hinzufügen, die die Skripte ein wenig verbessern, was aber an deren Funktionalität nichts ändert.