Beiträge von eiche

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 willst also die Energie bei negativen Leistungswerten für eine gewisse Dauer erfassen.

    Ich hatte davon zunächst eine andere Vorstellung ...

    Da ich derzeit keine solche Anlage besitze, kann ich nur assistieren.

    Frage: Woraus ergibt sich die vom Shelly gelieferte Information zur Energie?

    Ich vermute, dass aenergy hierfür nicht genutzt werden kann.

    Das Prinzip sollte folgendermaßen gelingen.

    Man erstellt einen Eventhandler, in welchem man das Ereignis mit den gewünschten Daten selektiert.

    Das eintreffende Event liegt in einem Objekt vor, welches man sich anzeigenlassen kann, um dessen Struktur zu analysieren.

    Es sind sowohl die Leistung (Komponente apower) als auch der Zeitstempel (Komponente ts = timestamp) zu nutzen

    Dies kann allerdings nicht genau sein, da hierbei nur Mittelwerte genutzt werden.

    Verbesserungsansatz (wäre zu testen, muss nicht zwingend funktionieren):

    Man definiert eine sog. Epsilon-Umgebung vor dem Wert 0, per

    let Epsilon = 1; // in Watt

    Liegt apower innerhalb dieser Umgebung, wird ts in Timestamp gespeichert.

    if(p<0 && p>-Epsilon) Timestamp = ts;

    Zu negativen apower-Werten wird jeweils die Energie wie oben berechnet und in Overage gespeichert.

    Sobald apower wieder innerhalb der Epsilon-Umgebung liegt oder positiv ist, wird der gespeicherte Overage-Wert gesendet.

    Ich kann dies derzeit nicht testen, voraussichtlich in 2024. ;)

    Der Epsilon-Wert ergibt sich aus realistischen apower-Werten und ist passend zur Anlage zu wählen.

    Die Genauigkeit hängt u.a. von der Abtastrate und den Änderungsschwellen zum Auslösen des Event in der Firmware ab.

    Edit:

    Eine Zeitspanne zum saldieren von Overage ist bisher nicht festgelegt.

    Hierzu wäre noch eine kleine Funktion overageReset() {Overage = 0;} einzubauen und ein Schedule Job anzulegen, welcher diese Funktion per Methode "Script.Eval" aufruft.

    Hierzu habe ich inzwischen eine Webseite erstellt, die das Anlegen eines solchen Jobs unterstützt. Das geht mit der WebUI derzeit nicht.

    Link dazu: https://tools.eichelsdoerfer.net/schedjob.html

    Edit 2:

    Alternativ oder ergänzend kann man auch dieses Overage-Rücksetzen per Nachricht vornehmen lassen, bspw. per MQTT Subscriber.

    Chriscross93

    Ich mag MQTT. Aber hierfür ist kein MQTT erforderlich.

    Wie apreick bereits meinte, ein DHT22 an einem AddOn zu einem Shelly wäre zielführend und verlässlicher.

    Einen H&T kannst du bei Versorgung per USB auch nehmen (sendet dann alle 5 Minuten), mit Batterieversorgung wird der H&T aber relativ selten senden.

    Ansonsten mit MQTT:

    Der Plus Plug S kann Skripte abarbeiten. Wenn du zum skripten (Subset von JavaScript) bereit bist, kann ein solches nützlich sein.

    dataprolet

    1. An MQTT topic is always a single one.
    2. Please describe or show your Node-RED flow!

    Do you use a JSON node after the MQTT in node?

    In a node after such JSON node you can access apower per

    Code
    msg.payload.apower

    Alternatively you may use the instruction

    Code
    let p = JSON.parse(msg.payload);

    in a function node. After that you can access the wished part, e.g. apower, per

    Code
    p.apower

    ...

    ostfriese

    Kleine Korrektur: Ich setze die Schedules per URL, außerhalb von Skripts.

    Es ist selbstverständlich auch möglich Schedules aus einem Skript heraus anzulegen und zu ändern.

    Und ja, es wäre imho wünschenswert, im WebUI eine Fortgeschrittenen (Profi) Abteilung für Schedules anzubieten.

    Dann wäre meine Webseite überflüssig.

    Die Schedules sind ja immerhin recht gut dokumentiert.

    Auch wenn die Lösung von SebMai vermutlich das vom TE Gewünschte abdeckt, so habe ich trotzdem für weiterführende Zwecke meine Webseite zum flexiblen nutzen von Schedule Jobs überarbeitet.

    Nun bietet sie folgendes.

    1. Anlegen von Schedule Jobs (Zeitplänen), welche nicht per WebUI der Shellies angelegt werden können.
    2. Ändern von solchermaßen angelegten Schedule Jobs.
    3. Entfernen jeglicher Schedule Jobs - einzeln.
    4. Wer sich mit der Syntax zum Eintrag timespec beschäftigt, kann alle Möglichkeiten dieser Schedule Jobs und der Methode "Script.Eval" nutzen.
      Dazu zählen sunrise, sunset (auch mit Offset), auf bestimmte Wochentage einschränken, auf bestimmten Monatstag festlegen, auf Jahresdatum (Monat, Tag) festlegen.
    5. Der Anwender dieser Website kann daran die Syntax des entsprechenden URL analysieren und kennenlernen, muss es aber nicht.

    Diese Website unterstützt somit die Verwendung der Kombination von Skripten und Schedules. Vielleicht kann sie noch nützlich sein.

    Der Link: https://tools.eichelsdoerfer.net/schedjob.html

    Ich empfehle für diese Webseite die Nutzung des Firefox Browsers, weil dieser die Antworten, insbesondere die Listings, übersichtlich darstellt.

    Bei Fragen hierzu stehe ich gerne zur Verfügung.

    So, nun steht eine Webseite zur Verfügung, die folgendes bietet.

    1. Anlegen von Schedule Jobs (Zeitplänen), welche nicht per WebUI der Shellies angelegt werden können.
    2. Ändern von solchermaßen angelegten Schedule Jobs.
    3. Entfernen jeglicher Schedule Jobs - einzeln.
    4. Es ist derzeit ausschließlich die Methode "Script.Eval" in diesen Jobs vorgesehen.
    5. Der Anwender dieser Website kann daran die Syntax des entsprechenden URL analysieren und kennenlernen, muss es aber nicht.

    Diese Website unterstützt somit die Verwendung der Kombination von Skripten und Schedules.

    Der Link: https://tools.eichelsdoerfer.net/schedjob.html

    Bei Fragen hierzu stehe ich gerne zur Verfügung.

    Edit: Ich empfehle für diese Webseite die Nutzung des Firefox Browsers, weil dieser die Antworten, insbesondere die Listings, übersichtlich darstellt.

    Das Einrichten der Schedule Jobs gelingt dann mit

    Code
    http://<Shelly_IP-address>/rpc/shedule.create?timespec="0 0 22 * * *"&calls=[{"method":"script.eval","params":{"id":1,"code":"enable(false)"}}]

    Dieser Job ruft täglich um 22 Uhr die Funktion enable(false) im Skript mit der Id 1 auf - da du nur ein Skript nutzt, möglichst ohne zusätzliche Experimente in anderen Skripts, hat dieses die Id 1. Diese Id kann man aber auch ermitteln ...

    Der zweite Schedule Job wird genau gleich angelegt, nur mit der Freigabezeit in timespec und dem Parameterwert true hinter enable (am Ende).

    Man kann dies auch kombinieren mit sunrise und sunset ... siehe hierzu: https://github.com/mongoose-os-libs/cron

    Vielleicht sollte ich gelegentlich eine Webseite erstellen, die man leicht zum Anlegen/Ändern eines solchen Schedule Jobs nutzen kann. Ich habe so etwas für ein Projekt getan, was aber nicht allgemein verwendbar ist.

    Mal sehen ...

    Edit:

    Wenn du später die Freigabe/Sperren-Zeiten ändern willst genügt folgendes:

    Code
    http://<Shelly_IP-address>/rpc/shedule.update?id=1&timespec="0 30 22 * * *"
    bzw.
    http://<Shelly_IP-address>/rpc/shedule.update?id=2&timespec="0 15 7 * * *"

    Die Id-Werte sind die der beiden Schedule Jobs, Job 1 zum sperren des Schaltens, Job 2 zum freigeben des Schaltens.

    Edit: Siehe auch Post #50

    Code-Beispiel:

    Edit:

    Diese Vorlage kannst du nutzen, allerdings ist die eintreffende Ereignis-Struktur (im JSON-Format) zu analysieren, um auf Grund dessen

    1. nicht passende Ereignisse wegzufiltern und
    2. wenn Ereignis passt, die beiden Werte für InpId und InpStat zu erhalten.

    Ich habe noch die Ausgabe der gesamten Event-Information (Parameter e) eingebaut - siehe print-Anweisung.

    Die täglich temporäre detached-Lösung fiel mir auch zunächst ein.

    Nachteil: Es wird täglich in den nichtflüchtigen Speicher geschrieben. Das ist zwar nicht schlimm, aber vermeidbar, wenn man will.

    Hier kommt mal wieder meine Vorliebe in Frage: Kombination aus Skript und Schedule Jobs ;)

    Prinzip:

    Die Eingänge werden fest auf detached konfiguriert.

    Das Skript enthält

    1. einen Eventhandler, der auf die Änderungen der Eingangssignale reagiert,
    2. eine Funktion enable(en), welche eine Skript-globale boolesche Variable EN auf den Wert des Parameters "en" setzt.

    Dazu werden zwei Schedule Jobs mit den passenden timespec-Einträgen, der Methode Script.Eval und dem Aufruf der Funktion enable() eingerichtet,

    der eine Job mit enable(false). der andere mit enable(true). Dies gelingt NICHT mit der WebUI, hier ist bspw. ein passender URL erforderlich.

    Der Eventhandler prüft den Wert von EN und lässt den dem Eingang zugeordneten Ausgang (gleiche Id) nur dann schalten, wenn EN true ist.

    Infos zu Scripts: https://shelly-api-docs.shelly.cloud/gen2/Scripts/S…anguageFeatures

    Infos zu Schedules: https://shelly-api-docs.shelly.cloud/gen2/Component…rvices/Schedule

    Bei Bedarf kann ich konkreter werden. ;)

    Eine Zentrale mit dem Raspberry Pi ist sehr nützlich.

    Ich nutze darauf kein fertiges Smart Home System, sondern Mosquitto, Node-RED, InfluxDB, Grafana und ein paar Shellskripte, die aber nicht notwendig sind.

    Diese Zusammenstellung bietet alles, was ich mir als zweckmäßig vorstellen kann.

    Allerdings muss man sich zur Nutzung in die drei letzten Werkzeuge mehr oder weniger einarbeiten.

    Ich nutze deshalb kein fertiges System, weil ich so am flexibelsten bin. Das, was ich bisher implementierte kann afaik kein fertiges System nach meinen Wünschen.

    Man kann afaik zumindest teilweise die o.a. Werkzeuge auch in ein fertiges System zusätzlich einbetten.

    Vielleicht hilft die dies zur Orientierung.

    Noch viel Erfolg ...

    Wenn du zu deinem o.a. Ziel und meiner Implementationsidee noch Fragen hast, kontaktiere mich einfach!

    Vermutlich beinhaltet der Pro 3EM einen ESP32, ich habe kein solches Gerät.

    Laut Beschreibung kann er Skripte abarbeiten. https://shelly-api-docs.shelly.cloud/gen2/Devices/ShellyPro3EM

    Daraus sollte sich folgende Implementationsmöglichkeit ergeben:

    1. Erstellen eines kurzen Skripts mit zwei Funktionen
      1. Eventhandler nimmt den jeweils aktuellen (strukturierten) Wert entgegen und speichert diesen in einer globalen Variablen im Skript (RAM)
      2. Senden einer MQTT-Nachricht (Beispielname send()), welche den/die gewünschten Werte in der Payload, ggf. JSON, sendet.
        Das MQTT Topic kannst du nach deinen Wünschen selbst wählen.
    2. Einrichten eines Schedule Jobs mit timespec="*/20 * * * * *" und der Methode Script.Eval zum aufrufen von send().

    Damit wird alle 20s eine MQTT-Nachricht mit den zuletzt erfassten Werten gesendet.

    Zu den Schedule Jobs siehe https://shelly-api-docs.shelly.cloud/gen2/Component…rvices/Schedule

    Bei Bedarf kann ich noch konkreter werden.

    Edit: Die vorgegebenen MQTT Nachrichten werden dann zwar gesendet, es gibt dann aber keinen Subscriber dafür, wenn dein Topic (im Skript) vom vorgegeben/konfigurierten Topic abweicht.

    Edit 2: Ich nutze sehr gerne die Android App "mqtt dash". Sie hat eine relativ schlichte Oberfläche, ist aber sehr flexibel nutzbar. Die "iot mqtt Panel" will ich mir mal ansehen.

    Edit 3: s.a. RE: Kombinierte Zeit-/Bewegungssteuerung zur Unterstützung beim Anlegen von Schedule Jobs, Post #50

    Noch eine Möglichkeit ...

    Ich nutze dafür Shelly i4 mit dazu passenden 4fach Tastflächen.

    Hierzu nutze ich ein Skript auf dem i4, an den Rollladen-Shellies habe ich keinen Taster angeschlossen.

    Vorteile:

    • Ich kann die 4fach Taster an einer günstigen Stelle einbauen.
    • Damit kann ich zwei Rollläden steuern.
    • Im Skript kann ich weitere Tasterfunktionalitäten implementieren, was ich auch tat.

    Nachteil: Solange WLAN ausfällt, kann ich meine Rollläden nicht bedienen - kam bisher nicht vor.

    Vermutlich gelingt der Einsatz des i4 für diesen Zweck auch per Konfiguration ohne Skript.

    Nachgereicht:

    Den Status eines Ausgangs per Methode "Switch.GetStatus", siehe auch https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/Switch

    Code
    Shelly.call("switch.getstatus", {id:<Id des Ausgangs>},
        function(status) {Out[<Id des Ausgangs>] = status.output;} // nach Doku, Struktur nicht geprüft
    )

    Du kannst ein solches Resultat leicht abfragen per

    Code
    http://<shelly_IP-address>/rpc/switch.getstatus?id=<Id des Ausgangs>

    Der Firefox zeigt das JSON-Resultat gut lesbar an.

    Soeben geprüft - die Struktur stimmt -> obiger Code ( = status.output) muss passen.

    Edit: WICHTIG! Unbedingt beachten.

    Eine Abfrage per RPC bzw. Shelly.call ist immer asynchron, d.h. es ist unbekannt, wann die Methode das Resultat (hier status) liefert. Dann kann einige ms dauern.

    Deshalb muss das Resultat zwecks späterer Verwendung gespeichert werden oder etwas mit dem Eintreffen des Resultats in der callback Funktion ausgeführt werden.

    Notfalls kann man nach dem RPC Aufruf einen Timer für einige ms starten und in dessen callback Funktion das gespeicherte Resultat verarbeiten. Dies ist allerdings nur eine Notlösung und nicht empfehlenswert, wenn es anders gelingt.

    Obiger Code lässt sich auch sehr gut in Funktionen unterbringen und so die Usability beim Coden steigern.

    Edit: Code in checkiAll hinter return leicht verbessert im Sinne der Verständlichkeit. ... und geringfügig gekürzt

    Prinzip:

    Dort, wo eindeutig geschaltet wird lässt du den Status des jeweiligen Ausgangs in einer globalen Struktur speichern.

    Dies gelingt ausschließlich beim toggeln nicht. Dort kannst du den Status per Methode "Switch.GetStatus" abfragen und den Status in der callback-Funktion speichern.

    Alternative: Du lässt mit dem Start des Skripts alle Ausgänge abfragen und speicherst deren Status in der Struktur. Dann geht auch beim toggeln das synchrone Speichern, solange der Shelly fehlerfrei arbeitet und sich keine Störung ereignet.

    Als Struktur bietet sich ein Datenfeld (Array) mit so vielen Elementen an, wie der Shelly Ausgänge besitzt.

    Beispiel: Nicht geprüft, aber vermutlich fehlerfrei und funktionstüchtig.

    Wenn du weitere Infos brauchst, lasse es mich wissen!