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.
Du solltest jemanden hinzuziehen, der sich mit elektrischen Dingen auskennt.
Dieser wird sehr schnell erkennen, dass
Schreibt die 3EM so was in ein Log, dass über WLAN auslesbar ist?
Wenn das geht, seit bitte so nett und postet den Code, mit dem man des Strom und auch den Betriebszustand auslesen kann.
Ich besitze keinen 3EM um dies zu prüfen.
Du kannst dich aber durch die Dokumentation arbeiten und experimentieren: Doku zum 3EM
Jedenfalls wird es möglich sein, die Daten zu holen - vermutlich werden die Daten im Shelly nicht protokolliert.
Es bleiben folgende Fragen.
Es muss sicher gestellt sein, dass die WP die Pumpe sofort einschalten kann.
Da gibt es afaik keine absolute Sicherheit, weil der Shelly per Kommunikation (Browser, Cloud, App -> Shelly) auch ausgeschaltet werden kann und afaik die Firmware keine Möglichkeit bietet, dies zu verhindern. Deshalb auch die Geräte-Empfehlungen von apreick.
Wie lange dauert es, wenn die Shelly Plus Plug S an 230V gelegt wird (Pumpe wurde von WP eingeschaltet) bis die Shelly über das WLAN Daten liefern kann?
Der Shelly sollte ca. 1 bis 2 Minuten nach dem Reboot Daten liefern (können). In einem Skript ist dies der Fall, per WLAN Übertragung ist das Gleiche zu erwarten.
Vergiss an dieser Stelle am besten die App. Nimm stattdessen einen Web Browser!
Vorher versuche, dein Endgerät (Notebook, Smartphone, Tablet) per WLAN mit dem Shelly zu verbinden, dessen SSID beginnt mit shelly ...
Dann gib in der Adresszeile des Browsers die Standard Shelly Access Point IP Adresse ein: 192.168.33.1
Dies teilte dir apreick bereits mit, ich versuche nur noch etwas eindeutiger zu beschreiben.
Wenn du ganz sicher bist, dass dein Endgerät mit dem Access Point des Shelly mini verbunden ist UND du im Browser mit der Adresse 192.168.33.1 keine Website vom Shelly erhältst, solltest du einen Factory Reset vornehmen.
Danach das Gleiche noch einmal versuchen - noch immer OHNE diese App!
Falls auch das keinerlei Erfolg bringt, d.h. du im Browser keine Website erhältst, dann kannst du dem Verdacht nachgehen, dass die Shelly mini defekt sind.
Ja, so begann ich im ersten Versuch zu diesem Thread, weil ich bereits mit solchen Schedule Jobs arbeitete.
Da aber "params" nicht wie erwartet funktionierte, und ich nach meiner Erinnerung irgend etwas stattdessen per "config" las oder herausbekam (?), ersetzte ich "params" durch "config".
Es bleibt nach wie vor leicht widersprüchlich, weil bspw. id und enable nach dem RPC von Input.GetConfig in der Response auf der gleichen und einzigen Stufe notiert sind.
{"id":0,"name":null,"type":"switch","enable":true,"invert":false,"factory_reset":true}Deshalb war das Naheliegende, den "calls" Eintrag so zu gestalten. --- !funktioniert nicht! ---
http://<IP Adresse Shelly>/rpc/Schedule.Create?timespec="@sunrise * * *"&calls=[{"method":"Input.SetConfig","params":{"id":0,"enable":false}}]Die eigentliche Schwierigkeit besteht darin, die funktionierende Objekt-Struktur bzw. dessen erforderlichen Einträge herauszufinden, da afaik solches nicht in der API-Dokumentation zu finden ist. Dazu hilft nur zielgerichtetes "Trial and Error" - am leichtesten per Skript. Sobald die Transformation der Shelly.call() Parameter in ein HTTP GET gekonnt ist, stellt diese Übertragung kein Problem mehr dar.
Wäre die Antwort von RPC Input.Config bspw. wie folgt, läge die richtige Syntax von Schedule.Create nahe und wäre leichter verständlich.
{"id":0,"config":{"name":null,"type":"switch","enable":true,"invert":false,"factory_reset":true}}! Obige Response ist nur zwecks Darlegung einer zielführenden Darstellung gedacht, sie kommt so nicht. !
Ich habe wieder etwas dazugelernt bzw. bin in zielführenden Versuchen etwas sicherer geworden.
Deshalb gilt mein Dank dir peru_19, weil du drangeblieben bist. 
Nach diesem Beispiel in der Doku kann man es ahnen und in zwei Schritten hin zum Schedule.Create übertragen, allerdings gehört dazu viel Sicherheit im interpretieren der API Dokumentation.
Heureka, ich fand die richtige Syntax. 
Zuerst habe ich festgestellt, dass ich per Web UI in der Input (0) Konfiguration nachsehen kann.
Hier die funktionierende Syntax:
http://<IP Adresse Shelly>/rpc/Schedule.Create?timespec="@sunrise * * *"&calls=[{"method":"Input.SetConfig","params":{"id":0,"config":{"enable":false}}}]Auf die Spur dieser Syntax kam ich per Experimente in einem simplen Skript.
Shelly.call("Input.SetConfig", {id:0, config:{enable:false}});Da es damit funktionierte, brauchte ich diese Parameterstruktur nur auf den Schedule Job zu übertragen - in JSON, die keys in Anführungszeichen.
Im nachhinein betrachtet ist es auch folgerichtig.
id=0&config={"enable":false} sind die Parameter der Methode Input.SetConfig.
Die Parameter werden im Schedule Job per "params"-Objekt (bzw. Struktur) festgelegt.
Somit lautet der einzige call: {"method":"Input.SetConfig","params":{"id":0,"config":{"enable":false}}}
Zur Freigabe des Input (0) lautet dann der call entsprechend: {"method":"Input.SetConfig","params":{"id":0,"config":{"enable":true}}}
Mit der aktuellen Firmware 1.2.2 lässt sich per Web UI, ohne Fehlerhinweis, der timespec Eintrag mit Klicks ... festlegen.
Damit ist es leicht, sunrise und sunset statt alle 15 Minuten einzustellen.
Vielleicht interessiert dich in diesem Zusammenhang mein Artikel Mächtige Schedule Jobs, den ich vorhin überarbeitete.
Ich bin gespannt auf deine Erkenntnisse.
Ich bin derzeit für voraussichtlich Wochen unterwegs und kann nicht mal eben einen Shelly zum testen greifen. Nur meine laufenden Shelly kann ich per VPN erreichen und damit ein wenig experimentieren. Da ich nun keinen Schalter betätigen kann (habe es versäumt, hierfür einen fernbedienbaren Shelly als Taster an einen anderen Shelly zu klemmen 
), kann ich letztlich derzeit die Funktionalität des Schedule Jobs nicht testen.
Somit wünsche ich dir viel Ausdauer und Kreativität. Ich werde interessiert deine Berichte lesen.
Edit:
"data": "shos_rpc_inst.c:230 Input.SetConfig via loopback "
Ich nutze die Diagnostics Protokolle sehr selten und bin in deren Interpretation nicht standfest.
"loopback" begegnete mir bisher im Zusammenhang von Skripten, die einen RPC auslösten.
Wenn diese Quelle auch für Schedule Jobs gilt, ist das bedauerlich, weil nicht hinreichend differenzierend.
Du wirst vermutlich bessere Möglichkeiten haben, dies genauer zu prüfen ...
In diesem Sinne - viel Erfolg!
Evtl. möchte der TE ja nur ein Tor für ne Katze öffnen/schließen
Jo, Präzision in der Status Quo Beschreibung ist offenbar recht selten.
was passiert wenn der sich mal "aufhängt" oder nen Reset gemacht hat?
Unabhängig davon, dass Hardware zwecks sicherheitsrelevanter Abschaltungen immer redundant zweckmäßig bis erforderlich sind, gibt es Möglichkeiten solche Situationen zu berücksichtigen.
Beispiel: Nur zur Verdeutlichung, ggf. zweckmäßige Erweiterungen habe ich nur erwähnt.
Es gibt einen Schedule Job, der im Sekundentakt den Antrieb ausschaltet und zeitgleich eine Skriptfunktion f() aufruft.
Steht das Skript (abgebrochen ...), dann läuft der Aufruf von f() in's Leere.
Arbeitet das Skript, kann f() den Antrieb einschalten, um dem Ausschalten entgegenzuwirken. Evtl. kann per Elektronik mit Integrierglied das Ausschalten analog geringfügig verzögert werden.
Das endgültige Ausschalten geschieht somit automatisch, wenn f() nicht mehr einschaltet, weil bspw. das Erreichen einer Endposition erkannt wurde.
Auf eine solche Weise ist auch mehr Sicherheit eingebaut, die rein softwaretechnisch realisiert ist.
Falls der Shelly hängt, d.h. nicht regulär (ohne Skriptlauf) arbeitet, kann ein Hardware basierter Watchdog ergänzt werden, der von einem zweiten Ausgang (Shelly Plus 2) regelmäßig "gefüttert" wird.
Für Letzteres ist ein weiterer Schedule Job geeignet.
Es gibt also durchaus einige Möglichkeiten für Sicherheitsaspekte, die zumindest teilweise per Software abgedeckt werden können.
Noch zum Reset: Das kann superleicht konfiguriert werden, indem der Shelly den Ausgang zum Antrieb nach Reset auf OFF stellt.
Nachtrag:
Ich habe den UNI gar nicht erwähnt weil das Risiko weiter durch Nutzung von Wlan steigt.
Das tut es nicht, wenn man den Shelly Plus Uni autark macht, wozu Schedule Jobs, Skript und Zusatzhardware geeignet sind.
Edit:
Btw, ein alter Analog-Timer wie der 555 sollte vermutlich als retriggerbarer Hardware-Watchdog geeignet sein. Dessen Einsatz liegt bei mir Jahrzehnte zurück, weshalb ich nicht ad hoc mit einer Schaltung dienen kann - und sicher auch nicht muss.
Edit 2:
Vielleicht tut es bereits eine digitale Schaltung mit CMOS-IC und Schmitt-Trigger Eingängen + Integrierglied - nur mal so.
Was DIYROLLY schreibt, kann ich nur bestätigen, insbesondere zu einer Torsteuerung - mit einem Rollladen wäre es vermutlich ein wenig weniger kritisch.
Mir ging/geht es ausschließlich um eine Machbarkeit.
Die Angabe unter Schedules "... Every 15 Minutes. Every Hours ..." zeigt, dass du im timespec nicht @sunrise verwendet hast, sondern etwas wie "0 */15 * * * *".
Jetzt gelesen, dass du das obige bereits erwähnt hast.
Ansonsten sollte der Schedule Job wie beabsichtigt arbeiten, wenn er enabled ist.
Das ist genau der gleiche RPC wie er auch im Schedule Job eingebaut ist, nur ohne Zeitsteuerung.
Ich habe momentan keine Erklärung für dieses von dir beschriebene Verhalten.
Allerdings ist ein solcher Schedule Job mit deinem timespec wenig sinnreich, es sei denn, du enablest irgendwie zwischenzeitlich die Component "input:0".
Gibt es bei deinem Shelly noch etwas, das Input (0) (="input:0") enablen könnte?
Um ziemlich sicher zu sein, sollte jegliche sonstige Kommunikation gesperrt sein. Dazu gehören
Klar kann man das per Skript lösen, aber vermutlich nicht einstellen.
Prinzip:
Ein Ereignis mit "component":"input:<id>" bei soeben gedrücktem Taster (event.info.state ist true) wird vom EventHandler erfasst, d.h. der Zeitstempel in event.now oder in event.info.ts wird gespeichert - sowohl die id als auch der Zeitstempel, ts1 genannt.
Ein zweites Ereignis mit "component":"input:<id>" bei soeben losgelassenem Taster (event.info.state ist false) wird erfasst und dessen id mit der gespeicherten id verglichen. Bei Übereinstimmung der Id wird der neue Zeitstempel verwendet, ts2 genannt.
Nur wenn ts2 - ts1 > deine definierte Dauer ist, wird die gewünschte Aktion per RPC, im Skript per Shelly.call(<Methodenname>, {id:<id Wert>, ...}) ausgelöst.
Wenn du Konkreteres brauchst, kannst du zumindest meine Skripteinführung verarbeitend lesen ... dann können wir weitersehen.
Edit:
Wenn es per Skript einstellbar sein sollte, braucht man dafür kein Skript.
Dann wäre es auch per RPC einstellbar, etwa so:
http://<IP Adresse Shelly>/rpc/input.setconfig?id=<Button Id>&config=...Ich sah per Methode Input.GetConfig nach. Da ist nichts zur Dauer für Longpush zu sehen.
Daraus folgere ich (vorsichtig), dass diese Einstellung seitens der aktuellen Firmware (Version 1.2.2) nicht vorgesehen ist.
Ich habe keinen Shelly Plus Uni, aber Erfahrungen mit anderen Shelly der zweiten Generation - und insbesondere mit Skripten.
Der Antrieb gibt via Poti die aktuelle Position aus, welche nicht überfahren werden darf.
Wenn ja, lässt sich das Schalten des Antriebes per Skript implementieren.
Aber Vorsicht: Im Programmieren ist Präzision gefordert.
Für Sicherheitseinrichtungen musst du dich, insbesondere wegen Eigenbau, selbst verantwortlich fühlen.
Mein Fazit:
Ich schlage vor, hk4711 lädt uns für min. 3 Tage ein, bewirtet uns fürstlich, stellt Übernachtungen zur Verfügung und erhält von 4 Gästen 10 Empfehlungen, ist total verwirrt und freut sich, wenn wir wieder weg sind so sehr, dass ihm die Installation egal ist.
Damit ist zumindest ein Aspekt seines Ziels erreicht.
Wie es uns danach gehen wird, kann ich noch nicht einschätzen. 
Edit:
Krauskopp , deine erste Antwort war bereits zielgenau unter der Bedingung eines Tasters auf der Fernbedienung. Zwei Taster sind einfach zu viel - für binäre Dinge.
Ok Martin - bei dir.
Soweit ich es verstand, liegen solche Möglichkeiten beim TE aber nicht vor.
Zielführende Empfehlungen kann es imho nur geben, wenn deine lokalen Gegebenheiten bzgl. Lampen und bevorzugten Bedienungselementen geklärt sind.
Ein übergeordnetes System, wie Martin es in's Spiel bringt, geht selbstverständlich, dann funktionieren die Lampen aber nur, solange dieses System verfügbar ist und richtig arbeitet - keine Autarkie im engeren Sinne.
Deine bisherige Ausstattung ist hinreichend autark. Ähnliches wäre bspw. mit Shelly i4 möglich - wie ich bereits erwähnte ...
Martin hat es skizziert und Stromopa (offenbar) gemalt. 
Ich kann eh nichts wesentliches auf diesen Fotos erkennen.
Ich habe unterwegs seiend keinen Shelly, den ich mir ansehen kann. Außerdem sind solche Fotos schwach gegenüber Schaltskizzen.
Danke Martin.
Dann bin ich auf eure weitere Zauberei gespannt. 
Ich glaube derzeit nicht, dass er zufrieden damit wird.
Na klar sind es Taster.
Es geht noch immer darum, ob je McPower Relais zwei Taster, einer zum einschalten und einer zum ausschalten, auf der Fernbedienung sind.
Oder ob es dort nur einen Taster gibt, mit dem das McPower Relais sowohl ein- als auch ausgeschaltet wird, also mit jedem Tastendruck auf diesen einen Taster das Relais umgeschaltet wird.
Nachdem du irgendwann (sorry) die Dinger richtig verdrahtet haben wirst, wird genau diese Fernbedienungsfrage entscheidend dafür sein, ob dein Ziel handhabungstechnisch erreichbar ist oder nicht.
Gibt es von McPower (kannte ich bisher nicht) auch Fernbedienungen mit einem Taster?
Mit solchen müsste dein Ziel erreichbar sein.
Man kann auch ohne das McPower Relais ausschließlich mit den Shelly arbeiten und i4 verwenden.
Das gelänge dann ohne übergeordnetes System.
Das ist aber erst interessant, wenn du an einer Stelle per 4 nebeneinander liegender Taster 4 Verbraucher schalten möchtest - oder wenigstens 3.
Das müsste zwar nicht sein, dann tätest du aber vom i4 bspw. nur ein Viertel seiner Möglichkeiten nutzen - und du bräuchtest relativ viele davon.
