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.
Jo.
Die RC Kombination (es gibt noch eine andere Variante) ist nur wegen der relativ trägen Analog-Digital-Umsetzung erforderlich.
RC sorgt dafür, dass bei loslassen des S2 die Spannung relativ langsam sinkt und die analoge Eingangsspannung eindeutig als "High erkannt" wird.
Es muss geprüft werden, ob die analoge Spannung über einem bestimmten Wert liegt, bspw. >5V => als High interpretieren.
Hier der verschlankte Code inkl. Schalten und übersichtlicheren Einrückungen - ungetestet:
let CONFIG = {
BKW_time: 5 * 1000,
BKW_URL: "http://192.168.178.7/EVUM.txt",
EinSchwelle: 200, // bzw. dein passender Wert
AusSchwelle: 50 // bzw. dein passender Wert
};
function timer_start(){
Shelly.call(
"HTTP.GET", {url: CONFIG.BKW_URL},
function(result) {
print(result.body); // nur zum kennenlernen der Antwort
let value = JSON.parse(result.body); // Text in Zahl umwandeln
if(value > CONFIG.EinSchwelle) Shelly.call("Switch.Set", {id:0, on:true});
if(value < CONFIG.AusSchwelle) Shelly.call("Switch.Set", {id:0, on:false});
}
);
}
Timer.set( CONFIG.BKW_time, true, timer_start);Hiermit ist eine Schalthysterese zwischen Ein- und Ausschalten implementiert. Vermutlich willst du das so.
Viel Erfolg damit!
Die Namen der CONFIG Komponenten erscheinen mir zu speziell zum BKW gewählt. Ich wollte aber deinen Code nicht allzu sehr verändern. 
Statt BKW_time wäre Request_Period gut geeignet, statt BKW_URL einfach nur URL.
Statt "timer_start" wäre bspw. "process" (für verarbeiten) oder "request" (für anfragen, anfordern) passender gewählt.
Das Ein- und Ausschalte gelingt mit der Methode "Switch.Set" und dem Parameter im JSON Format {id:0, on:true} bzw. {id:0, on:false}.
Ich entnehme deinem Skript Code, dass es sich um ein Balkon PV Kraftwerk handelt.
Der Skript Code lässt sich verschlanken, das Schallten in der (unbenannten) callback Funktion des Shelly.call() Aufrufs passend unterbringen.
Diese Zahl steckt offenbar in einer Textdatei.
Was erzeugt denn eine solche Zahl?
Welches Gerät (wegen IP Adresse) liefert diese Textdatei?
Prinzipiell könnte ein Node-RED Flow eine solche Zahl per HTTP Request an einen Shelly liefern, der per Skript (Stichwort HTTP Endpoint) eine solche Zahl verarbeiten könnte.
Das ist insgesamt für deine Anfänge viel zu kompliziert.
Beschreibe bitte mal den gesamten Zusammenhang!
Welche Geräte sind beteiligt?
Welches Gerät soll den Shelly dazu bringen, ein- oder auszuschalten?
Welcher Anlass liegt für das Schalten vor?
Es gibt vermutlich einen relativ einfachen Weg, dein Vorhaben zu realisieren.
Eine Diskussion darüber hier ist tatsächlich wenig angmessen.
beim Erstellen des ersten Accounts hat das System gemeckert, weil zu kurz.
Daraufhin habe ich sie zwei Buchstaben noch angehängt.
Du schließt bei den Wörtern "ersten Account" darauf, dass es der zuerst angelegte sein müsse. Das ist aber ein schwacher Schluss, weil ebendies nicht gemeint sein muss.
Nur mal so als Anregung ...
Ich war auch zunächst etwas irritiert. Ich vertraue ihm aber schon deshalb, weil ich nicht erkennen kann, wo er sich bisher irgendetwas hat zu Schulden kommen lassen.
Von Tasmota habe ich in diesem Thread nichts gesehen (evtl. übersehen). Die Web UI galt einem evtl. möglichen Power Offset.
Was ist euer Antrieb, den Verdacht auf zwei "Anfänger" Accounts derart zu verfolgen?
Zur flexiblen Nutzung von Schedule Jobs habe ich für Anfänger einen kurzen Artikel geschrieben: Mächtige Schedule Jobs
@opoel Einen Aspekt möchte ich noch hinzufügen.
Du kannst ja auch einen längeren zeitlichen Sendeabstand wählen. Dazu kannst du die von dir gewünschten Werte im Skript berechnen und zwischenspeichern, auch mehrere bis viele Werte.
Der Kreativität sind keine Grenzen gesetzt. 
@opoel
gibt es eine Möglichkeit, den Shelly per Script dazu zu bringen, minütlich so etwas wie einen Mittelwert zu liefern?
Ja, die gibt es. Per Timer oder besser per Schedule Job. Aber ... die Messwerte treffen vermutlich sowohl in kürzeren als auch in längeren Abständen als 1 Minute ein. Das stellt zwar kein Problem dar, ist aber, die Werte betreffend, leicht fragwürdig. Die Werte können ja leicht zwischengespeichert und der letzte Wert (oder ein gemittelter Wert) zur nächsten vollen Minute übertragen werden. Zum Zeitpunkt der Übertragung kann sich aber der tatsächliche (noch nicht gemessene) Wert verändert haben.
Wenn das für dich Ok ist, kann ich dir empfehlen, ein Skript zu erstellen mit einem Eventhandler zwecks Entgegennahme des Messwertes und dessen Speicherung (ggf. + Verarbeitung) und einer Funktion "send()".
Dazu ist ein Schedule Job zu erstellen, der per timespec="0 * * * * *" zu jeder vollen Minute per Methode "Script.Eval" die Skriptfunktion send() aufruft ...
Der timespec Wert (Zeichenkette) kann später relativ leicht per Web UI geändert werden, jedenfalls in der Firmware Version 1.2.0.
Edit:
Das Senden eines Mittelwertes ist selbstverständlich dann zielführend, wenn zwischen zwei Sendungen mehrere Messwerte (per Firmware und Event) eintreffen. Ansonsten kannst du deine Mittelwerte selbstverständlich so (ggf. nachführend) berechnen lassen, wie es dir gefällt.
Wie bitte stellt man an dem 1PM den Offset ein?
Ich kann das derzeit nur mit AddOn testen/nutzen. Dort kann man bspw. zur gemessenen Temperatur ein Offset eintragen
Home -> Temperature (100) -> Stift -> Offset ...
Ansonsten geht so etwas per (kurzem) Skript oder beim Empfänger - per Node-RED ist das ein Kinderspiel.
Ich fragte aus gutem Grund nach seinem Plug S. Ich weiß nicht, welchen er hat.
Nach seinem Text hat er vermutlich keine Ahnung vom Skripten.
...
Das lässt sich ja leicht vermeiden.
Ich könnte ein Beispiel zusammenstellen, wenn ich genügend Muße dazu habe.
Auf die Schnelle mal hier die Grundlagen.
Variante 1: (offenbar bereits von dir implementiert)
Zu den nicht sehr regelmäßig eintreffenden Werten die Zeitstempel holen und damit die zwischenzeitlich gelieferte/verbrauchte Energie berechnen. Ergebnis senden.
Variante 2:
Immer, wenn ein neuer Wert eintrifft, diesen zusammen mit dem Zeitstempel in einem Datenfeld (Array) ablegen. Prüfen, ob Werte mit "abgelaufenen" Zeitstempeln (älter als bspw. 5 Minuten) im Datenfeld liegen, ggf. diese entfernen.
Im Schedule Job wird per Methode "Script.Eval" eine Funktion deines Skript aufgerufen, ich nenne sie mal "send()". Diese Funktion sendet den per Skript berechneten Mittelwert bzw. den diskret integrierten Wert.
Ob du diesen mit jedem Eintreffen eines neuen Wertes berechnen lassen willst oder erst mit dem Aufruf von send(), bleibt dir überlassen.
Mit Variante 2 werden in regelmäßigen, von dir festlegbaren Abständen Werte gesendet. Zum Anlegen eines geeigneten Schedule Jobs mit Methode "Script.Eval" ist derzeit die Web UI nicht geeignet. Hierfür habe ich eine Webseite erstellt, welche dies unterstützt:
Zum anlegen von Schedule Jobs mit Methode Script.Eval sowie ändern, löschen von Jobs
Die Zeiten bzw. Abstände solcher bereits angelegter Jobs kann man mit der Firmware Version 1.2.0 inzwischen sehr gut und relativ leicht ändern.
Der timespec Wert für minütliches Senden rund um die Uhr und täglich lautet "0 * * * * *".
Eine Quelle für so etwas liegt in meinem Kopf. (selbst kreiert und genutzt)
Edit:
Falls es in den Messwerten Ausreißer gibt, könnte eine "Mediane Mittelwertbildung" genutzt werden. Hierfür sind die wenigen Messwerte (mit Zeitstempel) in ein Datenfeld einzusortieren - insertion sort genügt. Der Wert in der Mitte bzw. die zwei in der Mitte des Datenfeldes liegenden Werte (noch einmal mit (val1+val2)/2 mitteln) ist dann der Mediane Mittelwert. Evtl. ist dieses Verfahren für deine Zwecke geeignet. Es kann bei einseitigen Ausreißern noch optimiert werden. Mit diesem Verfahren ist das Datenfeld nach dem Senden bzw. ermittelten Mittelwert zu leeren, um darin nur die nachfolgend eintreffenden Werte zu speichern.
Edit 2:
Eine Korrektur von ggf. auftretenden Messfehlern kann nur optimiert werden, wenn solche Fehler genauer und sorgfältig analysiert werden, wozu eine möglichst dichte Aufzeichnung der Daten erforderlich ist. Hierzu könntest du eines meiner Projekte für deine Zwecke anpassen, welches ich hier beschrieben habe, noch ohne Skript-Offenlegung: Autarke Temperaturmessung 2.x per Shelly Script
Damit lassen sich viele Messwerte auf dem Shelly persistent zur späteren Übertragung speichern und somit später analysieren.
Zu ungenutzten Relais eines Shelly / ersetzen durch Shelly ohne Relais ...
Vielleicht für kleinere Typenvielfalt im eigenen Vorrat und schnellerer Austauschbarkeit im Fehlerfall?
@opoel
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:
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.
Ich warte jetzt erst einmal auf eine Fehlermeldung von Cyb.2K
Ich warte ... -> Wir warten ...
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.
