Tatsächlicher Stromverbrauch bei gleichz. vorhandener Eigenerzeugungsanlage

[KölnSolar]

Hallo zusammen,

ich möchte in diesem Thread die verschiedenen Lösungsansätze zur Ermittlung des tatsächlichen Stromverbrauchs bei gleichzeitig vorhandener Eigenerzeugungsanlage sammeln und diskutieren.

Ausgangssituation:
Unabhängig von speziellen und integrierten Lösungen mit Devices wie z.B. SMA Sunny Homemanager haben Eigenerzeugungsanlagen in der Regel einen 2-Richtungszähler verbaut. Aus den meisten dieser modernen Zähler lassen sich mit relativ geringem Aufwand Daten auslesen(die unterschiedlichen Technologien sollen hier nicht diskutiert werden). Fast immer sind es die Zählerstände für Strombezug und Stromeinspeisung. In meinem Fall(Hager ehz) noch zusätzlich die elektrischen Größen Strom, Spannung und Leistung je Phase. Mein Zähler sendet die Daten permanent, während andere Zähler dazu aufgefordert werden müssen. Meiner sendet Klartext(OBIS) und manche verschlüsselt(SML). Mit dem OBIS-Modul von Stefan(nochmals Danke dafür) können die Klartext-Zähler hervorragend in FHEM eingebunden werden.

Aufgrund der vorhandenen Eigenerzeugungsanlage lässt sich aber nicht darstellen, welche aktuelle Verbrauchsleistung im Objekt vorliegt bzw. wie hoch der eigentliche Stromverbrauch ist, da ja teilweise Strom vom Versorger und teilweise eigenerzeugter Strom verbraucht wird.

Einfache Formel dazu: Verbrauch/Leistung = Bezug/Leistung + Erzeugung/Leistung - Einspeisung/Leistung

Zum Glück lässt sich die Erzeugung entweder aus einem "Erzeugungszähler" oder aber aus Wechselrichtern auslesen. Man hat also ein zweites Device. Auf die einzelnen Schnittstellen soll hier auch nicht weiter eingegangen werden.

Weil die gewünschten Daten im Kontext am besten zum device Zähler passen, habe ich also dort mittels userReadings gem. obiger einfacher Formel weitere Readings angelegt.

Problematik:
Die beiden Devices liefern ihre Daten nicht synchron und die Erzeugung kann schnell und stark schwanken. Die Plots  sehen dann gar nicht mehr so hübsch aus bzw. Analysen sind nicht mehr möglich.

Lösungsansätze und Bewertung:
1.) Leseintervalle möglichst klein halten, um die evtl. Asynchronität zu minimieren. Nachteil: Systemperformance, Datenvolumen
2.) Mittelwerte bilden, um die Schwankungsbreite zu reduzieren. Nachteil: schwierig universell in fhem zu realisieren
3.) die beiden Devices synchronisieren. Nachteil: Großes Wissen zum System- und Deviceverhalten; Ausreisser

Meine Lösung:
Ich habe mich für 3.) entschieden. Meine Wechselrichter lassen sich gezielt abfragen und sind über ein selbsterstelltes Modul in fhem eingebunden. Das OBIS-Modul liefert im 1-min. Intervall die Zählerdaten. Damit die für die userReadings zu verarbeitenden Erzeugungsdaten möglichst zeitnah sind, habe ich ein notify auf ein Zähler-Event gelegt, welches dann mittels defmod eines at die Daten der Wechselrichter mit einem Zeitversatz (aber eigentlich kurz vor Ausführung des OBIS-Moduls in 1 min.)pollt

Code Auswählen Erweitern

define xyz at zaehler:.*VLeistung_W3.* defmod call_wechselrichter at +00:00:58 get Wechselrichter_Daten

Das Ergebnis seht Ihr im Anhang. Der obere Plot zeigt "Rohdaten" der devices und der 2. Plot zeigt die berechneten Verbrauchsleistungen. Rot sind die Daten für Phase 1(keine Eigenerzeugung). Blau und Grün sind die Zählerdaten der Phasen mit Eigenerzeugung. Und für Phase L2 wird in pink zusätzlich die Erzeugungsleistung des Wechselrichters geplottet.

Ich meine im Ergebnis schon nicht schlecht, aber als um 14:30 die Wolken kamen, kamen auch die dicken Ausreisser  Und nicht über den Versatz zw. Pink und blau ab 16:45 nachdenken. Da hat mein Sohn seinen PC eingeschaltet und verbraucht etwas Strom.

Ich scheine datentechnisch noch einen nicht erklärbaren Vorlauf der Wechselrichterdaten gegenüber dem Zähler von 1 min. zu haben, obwohl der Mechanismus mit dem notify perfekt funktioniert. Ursache suchen ist mein Job.

Was haltet Ihr von der Lösung, wie sehen Eure aus ?

Grüße
Markus

[KölnSolar]

na, wenn keiner will, dann eine weitere Alternative die ähnlich funktioniert:

Dank des alignTime Attributs lässt sich das OBIS-Modul(Danke Stefan) sekundengenau steuern. Und der at Befehl hat ja ebenfalls das alignTime Attribut.

Mit attr zaehler alignTime 00:00:00
und
define call_wechselrichter at +*00:01:00 get Wechselrichter_Daten
attr call_wechselrichter  alignTime 00:00:59

sollte die Synchronisation für pollende Zähler gut funktionieren.

In meinem Fall des permanent sendenden Zählers gibt es aber noch eine bisher nicht gelöste lange Laufzeit des OBIS-Moduls, die im Test zu einem spread von bis zu 11 Sekunden führte

[willybauss]

Ich hatte es auch mal mit der Formel für den Eigenverbrauch versucht, bin aber ebenfalls an den asynchronen Auslesezeiten der Zähler gescheitert. Es ergaben sich dann teils negative Eigenverbrauchswerte, wenn sowohl PV als auch der Verbrauch sich schnell änderten. Ich habs dann wieder bleiben lassen-
Mit der Synchronisierung über das alignTime Attribut könnte ich es ja nochmal versuchen. Wird dabei der Zeitpunkt, wann der OBIS-Zähler gelesen wird, über einen externen Trigger gesteuert (z.B. ein neuer Datensatz des des PV-Zählers triggert das Auslesen des OBIS-Zählers) ??

Übrigens kann mein OBIS-Zähler nur die Zählerstände ausgeben. Um dennoch an Leistungswerte zu kommen, bediene ich mich der "differential" Methode der userReadings: es werden 2 aufeinander folgende Zählerauslesungen sowie deren Timestamps verwendet und daraus die Durchschnittsleistung in diesem Zeitraum berechnet. Das klingt zunächst ungenau, passt aber trotzdem recht gut, weil die Timestamps auf Millisekunden genau sind.

[KölnSolar]

es ist kein direkt abhängiger Trigger. Schau Dir meine obige Def und die commandref des at zu alignTime an. Durch das alignTime erreicht man, dass das nächste Intervall nicht auf Basis des aktuellen Zeitpunkts, sondern eben relativ zu alignTime berechnet wird. In meinem Beispiel wird der Zähler immer zur vollen min. und die Wechselrichter eine Sek. vorher gelesen.

Nur die Gesamtleistung ist zwar wenig, aber auch schon ganz schön erhellend. Im anhängenden Plot sind Kochen, Kaffe kochen, Spülmaschine auch schon recht gut erkennbar. Ausreißer der Erzeugung kaum wahrnehmbar.

Kannst Du für die Erzeugungsleistung Daten pollen ?

Grüße
Markus

[Icinger]

Ich kann auch gerne ein "set OBIS readNow" einbauen, um das Auslesen der Daten zB mittels notify triggern zu können, wenn ihr wollt.

Dann gibts vlt. max. ne Sekunde Versatz oder so.

[KölnSolar]

Stefan, Danke für das Angebot. Ich denke aber, dass das erst erforderlich würde, wenn jemand at als Anstoß für das Auslesen der Erzeugungsleistung nicht nutzen kann.
Wichtiger ist, dass Du für unsere "pushenden" Zähler eine zeitnahe Verarbeitung für einen ganzen Datensatz hinbekämst oder siehst Du da keine Chance ?
Grüße
Markus

[Icinger]

Zeitnaher als jetzt wüsste ich nicht, wie gehen soll.

Ab dem <interval>-Zeitpunkt wird die Schnittstelle eingelesen und sobald die erste komplette Nachricht eingelagt ist, ausgewertet.

[KölnSolar]

im OBIS-Thread hatte ich ein Beispiel mit 6 sec." Verarbeitungsdauer" gepostet. In einem Fall hatte ich sogar 11 sec. Da bringen dann alle Sychronisationsbemühungen nicht viel.
Ich hab da noch ne Idee, die ich im OBIS_Thread poste.
Grüße
Markus