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.
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:
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.
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>×pec="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.