Balkonkraftwerk - Akku - Shelly 3EM Kauf- und Beratungsthread

SkyBird1980 - mag interessant sein, aber nicht zur Bestimmung der Saldierung - oder missverstehe ich dich da?

Mit Leckstrom meinst du Fehlstrom (Wie in Fehlstromschutzschalter)? (Leckstrom meint doch normalerweise was anderes: Leckstrom – Wikipedia).

Um dann vom Thema noch weiter abzuschweifen: Nach meinem Verständnis muss die Summe aller Ströme I(L1)+I(L2)+I(L3)+I(N) stets Null ergeben (Shelly macht es wohl über die Effektivwerte/RMS). Wenn das nicht der Fall ist, fließt was über Erde ab, und der Fehlstromschalter schlägt eh an. Oder, und so steht es etwas unpräzise oder unverständlich in den Shelly Dokus / Foren, damit kann man "energy theaft/energy leakage" erkennen. Wie soll denn da gestohlen werden? Eine Phase irgendwo angezapft und über anderen Nullleiter oder Erde abgeführt? Kommt mir relativ unrealistisch vor, dass sowas hinter dem Shelly passiert.

Lasse mich da gerne korrigieren - bin ja kein Elektriker, bilde mir aber ein die nötigen physikalischen Grundlagen zu verstehen.

Erinnert mich an Brasilien vor vielen Jahren, wo Straßenküchen mit hochgeworfenen Fleischhaken o.ä. die Stromleitung anzapften.

Meine 1,5 Jahre alte Firmware zeigt übrigens noch kein N an, habe ich aber in neueren Screenshots gesehen. Differenz RMS Strom N und L1+L2+L3 scheint mir da maximal gut zu sein die Messgenauigkeit zu prüfen. Wenn die Werte nicht gleich sind, sind die Messspulen nicht exakt kalibriert.

te36 - aus deiner Antwort soll ich schließen, dass du die von mir genannte Methode zur Saldierung als nicht korrekt erachtest?

Zitat von buers

SkyBird1980 - mag interessant sein, aber nicht zur Bestimmung der Saldierung - oder missverstehe ich dich da?

Ja, vollkommen irrelevant. Die Saldierung selber ist solange ich das Gerät hatte nur in der Webgui angezeigt worden und stand nicht per API oder MQTT zur Verfügung. Das meinte ich damit. Und man möchte das ganze ja meistens Extern weiter benutzen.

Zu Leckströmen: Sind halt Ströme die halt anderswohin fließen. Fehlerströme. Die Würde ein FI Schutzschalter auch erkennen. Aber man könnte z.B. mit dem Relais des Shelly3EM diesen Fehler signalisieren.

Der N kommt auch nur dazu wenn man den passenden Wandler angebaut hat. Der ist ja wie geliefert nicht dabei. Wie Du schon richtig sagtest braucht man das halt nur in Spezialfällen.

Zur Genauigkeit: 1% bei allen was über 2 Watt ist find ich schon in Ordnung. Die sind ja nicht umsonst überall empfohlen wenn man sich kein richtiges Smartmeter holen mag.

Zitat von SkyBird1980

Die Saldierung selber ist solange ich das Gerät hatte nur in der Webgui angezeigt worden und stand nicht per API oder MQTT zur Verfügung.

Ja, ich kenne das auch nur so, dass man sich das in anderen Systemen selber zusammen basteln muss:

Shelly 3EM in Home Assistant einbinden und dabei diverse Fehlerquellen entdecken und vermeiden - Anleitungen / Projekte - simon42 Community

Ich habe ein WiFi Meter auf WEM3080T-Basis verbaut. Habe ich von "MyPV" und nutze ich zur Überschuss-Messung und -Einspeisung.

Zitat von SkyBird1980

Die Saldierung selber ist solange ich das Gerät hatte nur in der Webgui angezeigt worden und stand nicht per API oder MQTT zur Verfügung. Das meinte ich damit.

In allen Screenshots die ich sah, und APIs über die ich die Doku las steht eben weder in Webgui noch im API eine saldierte Energie zur Verfügung. Die saldierte Leistung alleine genügt nicht. Und die Energiewerte pro Phase ("total" in der API) nützen auch nicht, wie ich versucht hatte zu erklären.

Methodik wie man selbst saldieren kann, hatte ich angegeben. Vielleicht bisschen zu kompliziert ausgedrückt mit "numerische Integration" (Energie ist halt das Integral der Leistung über die Zeit). Praktisch in einem Algorithmus bedeutet es einfach Summe von jeweils momentaner Leistung mal Zeitintervall für das abgelesen wird. (Und dann halt das berücksichtigen, ob grade im Saldo momentan verbraucht oder zurückgespeist wird, das wird durch das Maximum(a,b) in meiner Formel ausgedrückt).

Die Genauigkeit meiner Shelly scheint auch gut. Die von Zählern ist ja erstaunlich schlecht laut Norm. Habe da den Verdacht, dass es so ist wie bei den Streichhölzern. Da ist (war?) auch Fehlermarge erlaubt, wie bei den Stromzählern. Sollten 40 drin sein, wegen Naturprodukt Holz 38-42 erlaubt. Es sind aber immer 38 drin. Würde mich nicht wundern, wenn die Stromzähler immer am oberen Ende der Marge messen. Jedenfalls ist es bei mir nahe dran, wenn ich Shelly und Zähler vergleiche.

Stromzähler – Wikipedia (Unser Zähler hat Genauigkeitsklasse A - 3,5%)

EDIT: BirdOfPrey - mir scheint dein zitierter Thread geht auch nur um Netto-Leistung. Das ist schön festzustellen, ob man grade (über alle Phasen gerechnet) mehr verbraucht oder erzeugt. Für die Abrechnung braucht man aber Energie.

Zitat von buers

te36 - aus deiner Antwort soll ich schließen, dass du die von mir genannte Methode zur Saldierung als nicht korrekt erachtest?

Ich habe Deinen zitierten Post eher als Frage gelesen, und Du hast da von Energie gesprochen, aber es muss korrekterweise dessen zeitliche Ableitung, also die Leistung saldiert werden. Das Saldo muss man dann halt wieder integrieren. Wenn da also, wie SkyBird1980 behauptet das Saldo nicht zur Verfuegung steht auf der API, dann muesste man idealerweise die angezeigte Leistung schon so haeufig wie moeglich abfragen wenn man da ein genaues Saldo und dann dessen Integral ausrechnen will. Weiss nicht, wie gut man das ueber die API hinbekommen koennte, e.g.: obs da ueberhaupt die Leistungswerte als stream mit fester Frequenz gibt oder ob man das regelmaessig alle paar sekunden oder so pollen muesste. Auf der device GUI scheinen die Werte zumindestens haeufiger als alle 3 Sekunden upgedated zu werden.

Wenn hingegen das Integral des Saldo auf der API zur Verfuegung steht, so wie auf der web GUI, dann reicht das aber auch nicht fuer die Verbrauchskostenrechnung solange man da fuer eine eingespeiste KwH nicht dasselbe bekommt, wie fuer eine konsumierte. In dem Fall braeuchte man ja ein separates Intgral ueber alle negativen Saldi separat von dem fuer alle positiven Saldi. Und solche zwei separaten Saldi sehe ich nicht auf der GUI. Also doch auch Handarbeit/hochfrequentes pollen AFAIK wenn man eine Solaranlage hat.

Sobald bei uns mal eingespeiste KwH soviel Einnahme bringen,wie konsumierte Kwh reicht halt die einfache Saldobildung zur Ermittlung der Stromkosten.

Hoffe mal, ich hab das richtig verstanden

Zitat von buers

Für die Abrechnung braucht man aber Energie.

Dafür gibt es in HA dann einen Riemann-Summenintegralsensor, der aus der Leistung Energie macht.

Integration - Riemann sum integral - Home Assistant (home-assistant.io)

BirdOfPrey - nein, das reicht so nicht. In #18 habe ich versucht zu erklären, warum nicht. Die von dir genannte Riemann-Summe macht genau das, was ich dort "numerische Integration" nannte. Allerdings fehlt da die Rücklaufsperre des Zählers (In meinem Post durch Maximum(total_power,0) berücksichtigt). Und das Ergebnis der Riemann-Summe deiner Methode kann man schon leicht ablesen im Shelly - das ist die Summe der total über alle drei Phasen für ein bestimmtes Zeitintervall total(L1,t2)+total(L2,t2)+total(L3,t2)-(total(L1,t1)+total(L2,t1)+total(L3,t1)); Ln die Phasen, Zeitintervall t1 bis t2). Aber auch hier fehlt dann halt die Berücksichtigung der Rücklauf-Sperre. Und wenn man Einspeise-Vergütung bekommt, zeigt meine andere Formel, wie man das berechnet.

Zitat von te36

und Du hast da von Energie gesprochen, aber es muss korrekterweise dessen zeitliche Ableitung, also die Leistung saldiert werden

Das kommt mir jetzt eher, wie eine semantische Spielerei vor. Ich denke, ich habe die Berechnung korrekt erklärt, und habe versucht auf das Wort "Saldo" weitestgehend zu verzichten, weil meines Erachtens nicht so ganz klar definiert. Die Ergebnisse der gezeigten Methode ist die Energie die man bezahlen muss und die Energie die man rückvergütet bekommt (möglicherweise oder typischerweise bei Balkonkraftwerken zu 0 €/kWh).

Es ist nicht ganz einfach. Der Schlüssel zum Verstehen liegt vielleicht auch darin, dass der Energielieferant in der Tat Rücklauf auf einer Phase mit Verbrauch auf der anderen Phase *gleichzeitig* verrechnet. Sprich man hätte konstant P(L1) 100W, P(L2) 100 W, P(L3) -150 W für eine Stunde, bezahlst man 50 Wh für diese Stunde. Hast man die nächste Stunde (L1) 100W, P(L2) 100 W, P(L3) -250 W, bezahlst man gar nix, speist 50 Wh ein. Die darfst du aber nicht mit den 50 Wh aus der vorherigen Stunde verrechnen. Ein rückwärst laufender Ferrari-Zähler würde das tun (und ist ab 2024 übergangsweise erlaubt).

Die Riemann-Summe in deinem Beispiel BirdOfPrey, würde den rückwärts laufenden Ferrarizähler simulieren. Das nennt man aber gemeinhin (nach meinem Verständnis) nicht saldierend

te36 - mein Programm pollt. Da hilft dir die Statistik. Noch habe ich keine Energie-Erzeugung - meine numerische Integration der Leistung bringt jedenfalls selbst bei 60 s Messfrequenz sehr exakt die von Shelly intern geführten Energiewerte raus. Ich schaffe locker 1/s Messfrequenz. (Kein HA oder so, C++ mit direkter Socket-Programmierung. Ist privates Bastelprogramm).

Man kann auch lokal historisierte Daten aus dem Shelly 3EM herunterladen, aus denen man die diskutierten Werte berechnen kann. Die Werte der letzten Tage haben dabei eine Messfrequenz von 1/Minute.

buers

Wenn du meinst. Ich weiß allerdings nicht, warum da die Rücklaufsperre fehlen sollte! Es werden ja explizit die Leistungen (und damit dann die daraus berechneten Energien) getrennt gezählt. Du kannst also genau berechnen, wie viel Energie bezogen wurde und wie viel eingespeist wurde.

EDIT: Ich beziehe mich hier ausschließlich auf die Lösung in Home-Assistant!

Um das in HA noch einmal etwas ausführlicher zu beschreiben, da mein Posting eins zuvor doch irgendwie nicht eindeutig ist:

Es wird ein Sensor angelegt, der die aus allen drei Phasen aufsummierte Leistung enthält.

      {{
      states('sensor.shellyem3_xxxx_channel_a_power')| float(0) +
      states('sensor.shellyem3_xxxx_channel_b_power')| float(0) +
      states('sensor.shellyem3_xxxx_channel_c_power')| float(0)
      }}

Daraus wird ein Sensor gebildet, der ausschließlich die vom Haus bezogene (saldierte) Leistung ermittelt:

{{ states('sensor.total_power')|float(0) if states('sensor.total_power')| int > 0 else 0 }}

Und aus dem lässt sich dann doch die ausschließlich bezogene Energie berechnen!? Oder habe ich gerade einen kompletten Denkfehler?

das addieren passt schon. power ist ja auch leistung, also Watt oder Kilowatt. Um daraus energie zu berechnen muss man das halt noch mit einer angenommenen Zeit multiplizieren fuer die man annimmt, das diese Leistung gueltig ist. Also z.b. das Abfrageinterval von moeglichst wenigen Sekunden.

Und wenn da wirklich ein rueckwaertslaufender Ferrari genommen wird, dann kannste die negativen Werte auch noch beruecksichtigen. Bei mir ist ja schon zwangsweise ein digitaler Zaehler drin, der erfasst ja separate die gelieferte und zurueckgespeiste Energie, da sollte man dann eben auch selbt die separat berechnen, also wenn man solaranlage hat eben nochmal zweiten sensor, der nur liefert wenn saldo kleiner null.

buers Glaube das saldieren bezieht sich nur auf das aufsummieren der leistungswerte, nicht darauf, was/wie man ueber die zeit integriert.

BirdOfPrey, sorry, wollte da auch nicht harsch klingen - das stimmt wie du es jetzt beschreibst wohl schon. Kenne jedenfalls die Syntax von HA nicht und das "int > 0... else 0" hört sich schon bisschen so an, als würden nur die positiven Werte berücksichtigt (für das komplette Bild fehlt noch das Integral). Ich meine mein Maximum(total_power,0) für Verbrauch und Maximum(-total_power,0) für Erzeugung war da auch klar. Mir scheint, wir sind da jetzt schon beim selben Verständnis angelangt- Egal ob Saldo genannt oder nicht - eigentlich sind 3 Werte interessant:

1. Energie, die der rückwärtslaufende Ferrarizähler anzeigen würde (und das kriegt man sehr leicht aus dem Shelly raus),

2. Energie, die man an den E-Lieferanten zahlen muss,

3. Energie, die man zurückspeist und ggf. - zu einem anderen Preis - vergütet kriegt.

2. und 3. zeigt der Shelly nicht von selbst an - wie man das rauskriegt, haben wir jetzt ausführlich besprochen. 2. ist die Energie, die ein Zähler mit Rücklaufsperre anzeigt. 2+3 zeigen wohl moderne Zähler an (ich habe keinen ...)

Zitat von te36

Auf der device GUI scheinen die Werte zumindestens haeufiger als alle 3 Sekunden upgedated zu werden.

Grade mal geprüft. Über API erhält man offenbar jede Sekunde einen neuen Wert. Bei geringeren Zeitdifferenzen wird der identische Wert geliefert. Mein Programm schafft ca. 7-10 Polls pro Sekunde. Die Werte sind dann alle gleich für eine Sekunde. Da braucht man sich aber keine Sorgen zu machen - die Genauigkeit wird lange reichen. Selbst bei 1 Minuten Intervall sehe ich über 1 Stunde praktisch keinen Genauigkeits-Verlust bei Integration der Leistung mit Poll-Intevall 1 s verglichen mit 60 s. Ist für mich auch plausibel. Die Statistik gleicht das aus.

Zitat von te36

Also doch auch Handarbeit/hochfrequentes pollen AFAIK wenn man eine Solaranlage hat.

Also keine Sorge davor. So hochfrequent muss es nicht sein. Die Arbeit macht der Computer. Mein Programm benötigt auf meinem grade erworbenen Billigst-PC kaum messbaren CPU-Verbrauch.

Nein, aber ein generisches Script um ein JSON zu verarbeiten sollte doch als Basis helfen, oder?

Hier ist doch was beschrieben, musst nur auf die keywords anpassen

Python JSON Parsing using json.load() and loads()

Understand use of json.loads() and load() to parse JSON. Read JSON encoded data from a file or string and convert it into Python dict

pynative.com

Ich denke, da gehört noch viel mehr dazu. Konfiguration (Namen oder IP, Messfrequenz, Timeouts) Namensauflösung, Verbindung zum Shelly (kann übrigens kein keepalive), Fehlerbehandlung (wenn er mal nicht antwortet, wenn ...), was machen mit den Daten (z.B. die diskutierte Ermittlung von Verbrauch/Rückspeisung), Wegschreiben der Daten. Das hatte yard2 jetzt nicht alles geschrieben, aber für "Auslesen des 3EM" reicht json parsen alleine nicht. Klar, Konfig könnte man auch hart codieren.

yard2 - wieso willst du Python? Weil du damit programmieren kannst?

Das hört sich für nach einem Nachbau des Trucki sticks an.

Lumentree oder SUN GTIL2, Meanwell Netzteil und Shelly 3EM ist genau dort im Einsatz