Beiträge von eiche

Zu ungenutzten Relais eines Shelly / ersetzen durch Shelly ohne Relais ...

Vielleicht für kleinere Typenvielfalt im eigenen Vorrat und schnellerer Austauschbarkeit im Fehlerfall?

@opoel

Zitat

Gibt es denn eine Möglichkeit, so etwas wie einen Mittelwert minütlich abzufragen?

Unabhängig von anderen Aspekten, die hier teilweise diskutiert werden, ja das ist möglich - per Skript und Zeitplan (Schedule Job).

Dazu bildet das Skript an Hand der eintreffenden Messwerte einen fortlaufenden Mittelwert, bspw. über alle in den vergangenen 5 Minuten eingetroffenen Werte.

Der Zeitplan triggert in den von dir gewünschten Abständen, bspw. jede volle Minute, das Senden des vorliegenden Mittelwertes.

Edit:

Die Schedule Jobs sind sehr flexibel einstell- und nutzbar. Es ist bspw. auch möglich, nur über eine eingeschränkte Tageszeitspanne solche Werte senden zu lassen. Oder der Shelly sendet zusätzliche Nachrichten zwecks Aktivierung/Deaktivierung der spezifischen Verarbeitung der Daten im übergeordneten System. Je "intelligenter" ein Endgerät ist, desto weniger muss eine Zentrale "ackern".

Das freut mich.

Wenn du Unterstützung beim Skript schreiben möchtest, darfst du dich gerne an mich wenden.

Ich habe derzeit keine PV-Anlage, kann dbzgl. also nicht mitreden, aber ...

Du schriebst, du hättest einen Raspberry (Pi). Ein wenig abhängig von dessen Generation (2, 3 oder 4) lassen sich damit Daten aufzeichnen. Dies gelingt erheblich besser und verlässlicher als per Cloud.

Allerdings ist dafür Arbeit zu investieren.

Die auf dem RPi zu installierenden Dinge sind:

1. Linux Betriebssystem (selbstverständlich)
2. MQTT Broker wie mosquitto (optional)
3. Node-RED (bevorzugt, weil relativ leicht nutzbar)
4. Influx als Zeitreihendatenbanksystem
5. Grafana zwecks Visualisierung der in einer InfluxDB gespeicherten Daten

Viele nehmen für so etwas lieber ein fertiges System. Ich bevorzuge diese Bestandteile, weil ich damit bisher noch alles genau so hinbekommen konnte, wie ich es haben will.

Unabhängig von einer RPi Ausstattung kann ein Plus 2 PM auch per Skript Daten lokal speichern und diese per MQTT oder HTTP übertragen. Ein solches Skript kann auch die von der Firmware erfassten Messwerte verarbeiten.

Bsp.: gemessene Spannung U, gemessene Stromstärke I ... oder gemessene Leistung P, Zeiten lassen sich leicht per Skript lesen und damit Zeitspannen dt ermitteln.

=> Energie bzw. Arbeit W = U * I * dt = P * dt , evtl. vorhandene Vorzeichenprobleme kann ich derzeit mangels Equipment nicht analysieren.

(Ich weiß, dass es besser dW = U * I * dt lauten sollte. )

Afaik liefert die Firmware auch Energiedaten, wobei ich nicht weiß, wie diese zu interpretieren sind.

Auch kann man die Zeiten, zu denen jeweils die (irgendwie gemittelten) Energiewerte zu speichern bzw. zu übertragen sind, per Zeitplan festlegen .

Damit will ich dich weder verwirren noch überfordern, sondern nur Möglichkeiten aufzeigen. Ich kenne deinen Kenntnisstand nicht. Du kannst dich auf meine Darlegungen einlassen oder davor zurückschrecken - kein Problem.

Ich halte jedenfalls eine Cloud Lösung für bequem, aber suboptimal.

Wer oder was soll denn die Antwort auf die HTTP Anfrage, auch request genannt, des Shelly Plug liefern?

Handelt es sich um einen der ersten (ohne Plus) oder der zweiten Generation (mit Plus)?

Die Shelly reagieren normalerweise auf eine HTTP Anfrage, welche eher ein Auftrag ist.

Ich empfehle dir das Lesen der reichhaltigen Dokumentation hier: https://shelly-api-docs.shelly.cloud/

Dort kannst du dich zu deinem Shelly durcharbeiten.

Wenn du einen Plus Plug S hast, kann man den per Skript zu fast allem bewegen.

Zu deinen Vorstellungen, die auf Grund deiner Formulierungen zu vermuten sind:

Kein HTTP Client kann einen Uniform Ressource Locator (URL) "aufsuchen" und schon gar nicht "von dort auslesen". Er kann nur eine Reaktion eines Servers anfordern.

Vielleicht kannst du hier mal ein konkretes Beispiel anführen, damit klar wird, wie du dir das, was du willst, vorstellst.

Zitat von ostfriese

Ich warte jetzt erst einmal auf eine Fehlermeldung von Cyb.2K

Ich warte ... -> Wir warten ...

Peter1984

Ein 24V Netzteil mit geringer Welligkeit der Ausgangsgleichspannung, der Shelly Plus Uni und ein Relais (evtl. ein SSR, Solid State Relais) wäre eine gute Lösung.

Alternativ das Netzteil und ein Shelly Plus 1 - jedenfalls ist es afaik ohne ein solches Netzteil problematisch.

Bei thgoebel kannst du irgendwo finden, wie ein Shelly auf Niedriggleichspannung umgerüstet werden kann. Dann kannst du aber auch gleich die Uni mit Relais verwenden.

Vielleicht kannst du den Mini an anderer Stelle einsetzen.

mario1102

Du könntest für den remote Zugriff auf deine Gartenhaus Shelly VPN versuchen. Dies ist sowohl im Gartenhaus Router als auch auf deinem Smartphone einzutragen und ggf. zu installieren (bspw. WireGuard).

Wenn die Gartenhaus Shelly nicht zu erreichen sind, ist es egal, mit welcher Software (App, Browser, ...) du sie zu erreichen versuchst. Es kann dann nicht gelingen.

Die Verwendung der Cloud ist eine weitere Möglichkeit, wenn du diese nutzen willst.

Dazu hat dir elektroman bereits wesentliches mitgeteilt.

Ein Skript wirst du vermutlich hier zur Verfügung stellen. Um es zu nutzen, muss der Anwender es kopieren und an passender Stelle einfügen. So ganz DAU darf er also nicht sein.

Alternativ kann ich für den Anwender eine URL-Zeile hier posten, die er ebenfalls kopieren muss und in die Adresszeile seines Browsers einfügen muss.

Da gibt es somit erst einmal keinen echten Unterschied.

Die nachträglichen Einstellungen in der Web UI, die Zeiten betreffend, sind relativ einfach und gelingen bestens.

Zur Vereinfachung des Schedule Jobs kann ich auch ein Skript für die benötigten Funktionen zusammenstellen, welche im Job per Methode "Script.Eval" genutzt werden können.

Imho ist der reine Skriptweg somit nicht eindeutig leichter.

So, nun muss ich hier weg, weil ich das Messdatenspeicherprojekt an den Freund und Auftraggeber übergeben werde, was Stunden dauern wird.

So, puuh, habe die Änderungsmöglichkeit von timespec eines Schedule Jobs in der Web UI getestet.

Es geht hier um solche Jobs, die nicht per Web UI angelegt werden können.

Die Zeitangaben des oben angeführten Jobs mit den zwei Methoden kann leicht in der Web UI geändert werden.

Beim auflisten wird unter "Do what" nur die erste Methode angezeigt, die auch nicht editierbar ist, aber die Zeitangaben können leicht geändert werden.

Für den TE bedeutet das:

1. Er braucht vermutlich kein Skript. Selbstverständlich kann er trotzdem ein solches verwenden.
2. Es müssen nur einmal zwei geeignete Schedule Jobs angelegt werden, was nicht ganz trivial ist - s.o.
3. Wenn die beiden Jobs vorhanden sind und passend arbeiten, können deren Zeitangaben relativ leicht per Web UI des Shelly geändert werden.

Im meinem nächsten Leben werde ich für den kompletten Service zur Verfügung stehen.

Edit:

Ein Skript könnte bspw. eine interaktive Webseite zur Verfügung stellen, in welcher man die Schedule Jobs komfortabel anlegen, löschen und ändern könnte.

Das wäre imho eine coole Implementation.

Edit 2:

In der Web UI ist unter Schedules der bereits vorhandene Job zu finden. Dort sollte bereits unter "Schedule type" Advanced Schedule selektiert sein. Wenn nicht, dann dort von Basic schedule auf Advanced schedule umstellen.

Nun stellt die UI sehr komfortabel die Zeiteinstellungen von Sekunden über Minuten bis hin zu Weekdays zur Verfügung - alles per klicken einstellbar, auch Sunrise oder Sunset mit offset, also zeitlichem Abstand zu Sonnenauf-, Sonnenuntergang.

Sehr komfortabel. Nur unter "Do what" sollte an einem solchen komplexeren Job nichts geändert werden.

Wer sich eine http-Zeile (s.o. Beitrag #97) mal in einer Textdatei mit ein paar Erklärungen ablegt, sollte solche Jobs relativ leicht erneut anlegen können. Ein nicht passender Job kann leicht per Web UI gelöscht werden.

Edit 3:

Man kann auch mehrschrittig arbeiten.

1. Man lege den Schedule Job mit enable=false und einem simplen timspec="0 * * * * *" (0 und 5 Asterisk, je ein Leerzeichen dazwischen) an. Wesentlich sind hier die Einträge hinter calls=, darauf muss man sich konzentrieren.
   Z.B. <IP Adresse>/rpc/Schedule.Create?enable=false& timespec="0 * * * * *"&calls=[{"method":"Input.SetConfig","config":{"id":0,"enable":false}},{"method":"Switch.Set","params":{"id":0,"on":false}}]
   Das hier vor timespec eingefügte Leerzeichen dient ausschließlich der hier richtigen Darstellung, es ist überflüssig oder evtl. gar störend.
   Zeigt der Browser eine Fehlermeldung, stimmt etwas mit der Syntax zum anlegen des Jobs nicht und muss korrigiert wiederholt werden.
   War die Eintragung erfolgreich wird etwas ausgegeben wie { "id": 4, "rev": 6 }. Hier hat der neue Job die Id 4 erhalten und die sechste Änderung wurde vorgenommen.
   Die führende 0 in timespec dient dazu, dass jede volle Minute der Job ausgeführt wird, nachdem dieser bspw. per Web UI enabled wurde.
2. Evaluationsschritt: Zur Prüfung nutze man im Broser <IP Adresse>/rpc/Schedule.List . Nun zeigt der Browser alle eingetragenen Schedule Jobs an (Edge und Firefox tun dies übersichtlich).
   Nach sorgfältiger Prüfung aktiviert man den neuen Job in der Web UI - Schiebeschaltersymbol rechts.
   Wirkung: Jede volle Minute (Sekunde 0) wird der Job abgearbeitet. Nun kann man zwischendurch per Web UI oder Schalter/Taster manuell Änderungen vornehmen wie Einschalten, Ausschalten, Eingang sperren/freigeben ... und beobachten, ob der Job das tut, was er tun soll.
3. Wenn alles so läuft, wie es soll, den Job deaktivieren - weiter mit 4. Wenn nicht, die Ursache suchen, den Job löschen und ihn verbessert neu anlegen - weiter mit 2.
4. Nun die gewünschten Zeiten per Web UI einstellen, den Job aktivieren ... und sich hoffentlich freuen.

Ist die Zeitspanne von einer Minute für die Evaluation zu kurz, verwende man folgenden timespec: "0 */5 * * * *" zum auslösen des Jobs alle 5 Minuten, für alle 3 Minuten entsprechend die 5 durch 3 ersetzen ...

Man wird hoffentlich Verständnis dafür aufbringen, wenn ich das ursprüngliche Anliegen von Cyb.2K nicht ganz getroffen haben sollte. Ich habe versucht, das Prinzip aufzuzeigen und kann gerne bei Bedarf versuchen, die Schedule Jobs für den TE konkret passend zusammenzustellen.

Viel zu umständlich

Mit Input.SetConfig und enable sollte dies viel leichter gelingen ... kommt vielleicht gleich noch ...

{
     "timespec": "0 0 22 * * SUN,MON,TUE,WED,THU,FRI,SAT",
     "calls": [{
         "method": "Input.SetConfig",
         "config": {
           "id": 0,
           "enable": false
         }
       }
     ]
}

und das Gegenstück

{
     "timespec": "0 0 8 * * SUN,MON,TUE,WED,THU,FRI,SAT",
     "calls": [{
         "method": "Input.SetConfig",
         "config": {
           "id": 0,
           "enable": true
         }
       }
     ]
}

Aus Zeitgründen nicht getestet. Es sollte aber locker funktionieren.

Btw. man kann selbstverständlich mehrere Methoden in das "calls" Array einbauen, also zeitgleich auch das Licht ausschalten.

{
     "timespec": "0 0 22 * * SUN,MON,TUE,WED,THU,FRI,SAT",
     "calls": [{
         "method": "Input.SetConfig",
         "config": {
           "id": 0,
           "enable": false
         }
       },
       {
        "method": "Switch.Set",
        "params": {
            "id": 0,
            "on": false
        }
       }
     ]
}

Dies sperrt im 22 Uhr den Eingang 0 uns schaltet den Ausgang 0 aus, beides mit einem einzigen Schedule Job - ungetestet, aber ziemlich sicher.

Wenn man den letzten Job neu anlegen will, gelingt dies so:

http://192.168.33.1/rpc/Schedule.Create?timespec="0 0 22 * * SUN,MON,TUE,WED,THU,FRI,SAT"&calls=[{"method":"Input.SetConfig","config":{"id":0,"enable":false}},{"method":"Switch.Set","params":{"id":0,"on":false}}]

Die Wirkung des Jobs habe ich noch nicht getestet, der Job wurde aber richtig eingetragen.

Will man nur den timespec im Job ändern, muss man sich die eingetragenen Jobs ansehen, die id des jobs finden und folendes zur Änderung auf 22:30 Uhr im Browser eingeben:

 http://<IP Adresse>/rpc/Schedule.Update?id=<job id>&timespec="0 30 22 * * SUN,MON,TUE,WED,THU,FRI,SAT"

Letztes (Anpassung/Änderung der Uhrzeit) könnte sogar per Web UI des Shelly auf relativ einfache Weise gelingen.

Hier gibt es ein gut dokumentiertes und relativ leicht anpassbares Beispiel: https://shelly-api-docs.shelly.cloud/gen2/Component…rvices/Schedule

mal hierher kopiert:

{
     "id": 1,
     "enable": true,
     "timespec": "0 34 17 * * SUN,MON,TUE,WED,THU,FRI,SAT",
     "calls": [{
         "method": "Switch.Set",
         "params": {
           "id": 0,
           "on": false
         }
       }
     ]
}

"id" und Wert (hier 1) wird nur bei Änderung des Schedule Jobs gebraucht.

"timespec" ist sehr flexibel nutzbar, hier für alle Wochentage, stattdessen täte es auch ein schlichtes Asterisk (*).

Um 17:34 Uhr wird Ausgang 0 ausgeschaltet.

In "timespec" kann man auch sunrise, sunset oder von - bis nutzen.

Nun kann man als Methode "Switch.SetConfig" einsetzen und die entsprechenden Parameter dazu.

Ich kreiere dies mal noch ohne Test:

{
     "timespec": "0 0 22 * * SUN,MON,TUE,WED,THU,FRI,SAT",
     "calls": [{
         "method": "Switch.SetConfig",
         "params": {
           "id": 0,
           "in_mode": "detached",
           "initial_state" : "off"
         }
       }
     ]
}

Die id und enable des Schedule Jobs habe ich weggelassen. Damit sollte täglich um 22:00 Uhr der Schalter/Taster jeden Einfluss auf den Schaltausgang verlieren.

Die gegenteilige Aktion wäre entsprechend zu gestalten - in einem weiteren Schedule Job.

Wichtig! Das sollte ohne irgendein Skript funktionieren.

Per http gelingt das Deaktivieren/Sperren des Schalters/Tasters folgendermaßen:

http://192.168.33.1/rpc/switch.setconfig?id=0&config={"in_mode":"detached","initial_state":"off"}

Das Gegenstück wird auch kein Problem sein.

Wie ich dies in einen Schedule Job einbauen kann, weiß ich noch nicht.

Ergänzung zum Skript-Wissen

(an dieser Stelle eher nicht off topic)

Diese Skripte arbeiten ausschließlich Ereignis gesteuert. Wer etwas anderes versucht, wird Schiffbruch erleiden.

Falls kein geeignetes Ereignis eintreten sollte, kann man solche mit einem periodisch arbeitenden Timer nachbilden.

Hierfür ist nach meinen Erfahrungen in den meisten Fällen ein Schedule Job besser geeignet, welcher allerdings anzulegen ist. Damit dies relativ einfach gelingen kann, habe ich dazu eine Webseite erstellt: tools.eichelsdoerfer.net/schedjob.html

Solche Schedule Jobs können durchaus den per Web UI angelegten hinzugefügt werden, allerdings (noch) nicht per Web UI.

Per aktivem Schedule Job wird schlicht eine Funktion im (laufenden) Skript aufgerufen, ggf. mit Parameter. Diese Skript-Funktion muss im Schedule Eintrag eingebaut werden, was nicht schwierig ist.

Hier kann jede Skript Funktion oder eine Anweisung eingetragen werden. Entscheidend ist, dass das Skript mit der einzutragenden Id läuft (running).

Auch das Eintragen bzw. Austragen eines Eventhandlers ist möglich.

Zum von ostfriese angestrebten Prinzip:

Erstelle im Skript zwei Funktionen "enableEventHandler()" und "disableEventHandler()", welche das tun, was ostfriese in #91 darlegte! Dann erstelle zwei Schedule Jobs, welche ebendiese Funktionen zu gewünschten Zeiten aufrufen ...

Edit: (für etwas Fortgeschrittene)

Wer mag, kann in einem Schedule Job auch das Auslösen eines Ereignisses per Shelly.emitEvent(...) implementieren. Dann kann ein beliebiges, vom Anwender/Entwickler bevorzugtes Ereignis ausgelöst und per Eventhandler, auch in mehreren Skripten auf demselben Shelly, verarbeitet werden. Das ist sozusagen das High End der zeitgesteuerten Verarbeitung.

Edit 2: (unmittelbar zum angestrebten Ziel des TE)

Vermutlich können sogar ohne Skript zwei Schedule Jobs das Ziel erreichen. Allerdings wären solche Einträge nicht simpel. Sie müssten die RPC Methode Switch.SetConfig nutzen. Vielleicht werde ich das mal testen. Und wenn mich der Affe beißt, könnte ich sogar eine Webseite speziell dafür erstellen ... mhh ...

Eine Zeit auf Gleichheit zu testen, halte ich für problematisch. Der Vergleich sollte eine Ordnungsrelation (<, >) beinhalten, damit er robust funktioniert.

Auch hier täten locker zwei Schedule Jobs greifen, welche solche Zeiten bzw. sunrise und sunset nutzen.

Edit: Nach meinen Erfahrungen arbeiten die Schedule Jobs verlässlicher als jedes Skript.

Möglicherweise ist eine Implementation, welche Schedule Jobs nutzt, doch zu bevorzugen.

siehe bspw. meine Postings #46, #47

Zitat von ostfriese

"script:1":{"id":1,"running":false,"mem_free":25200,"errors":["error"]}

Dies interpretiere ich als einen Fehler, der im Skriptablauf auftrat, zu welchem aber keine genaueren Informationen vorliegen.

Ich täte nun im Skript eine, oder mehrere, Ausnahmebehandlung(en) einbauen - Stichworte: try und catch

Zitat von ostfriese

"wifi":{"sta_ip":"192.168.0.22","status":"got ip","ssid":"nicht verbunden!","rssi":-75}

Korrektur: Die SSID lautet "nicht verbunden!", was nicht heißt, dass der Shelly nicht mit dem AP verbunden ist.

Nach einem kurzen Test sollte hier bei verlorener Verbindung zum AP stehen:

    "wifi": {
        "sta_ip": null,
        "status": "connecting",
        "ssid": null,
        "rssi": 0
    },

Überprüft mit einem Shelly Plus 1 und meinem Smartphone Hotspot, Firmware 1.2.0-beta1

Aber nur dann, wenn der Gen 2 mit einem Auge zwinkern kann.

leicht off topic, zur Begriffsklärung

Ein Server ist grundlegend Software, bspw. auch ein Skript.

Eine Aussage wie "Der Server steht dort.", womit zunächst Hardware gemeint ist, ist nicht ganz falsch, wenn die Hauptaufgabe des Computers ist, Server (Dienste) bereitzustellen.

Grundlegend ist sie aber falsch, weil Server, wie angemerkt, Software ist.

Vor diesem Hintergrund ist das Skript von ostfriese ein Server, welcher als Hardware einen Shelly der zweiten Generation braucht. Auf diesem Shelly läuft also der Server (Skript), welcher anderen Shellies, auch der ersten Generation zur Verfügung steht.

Ich hoffe, damit nicht noch mehr verwirrt zu haben.