Solaredge PV - Gesamtertrag statt Tageswerte

[yankee]

Das wissen wir noch nicht, oder? Also der Beweis wäre, dass im daily-log etwas falsches steht und in den Sekunden vor dem Eintrag im Dailylog das SE-Update-log korrekte Werte in die openWB.log geschrieben hat.

Doch haben wir....

Hier die openwb.log 20:00-20:30 Uhr:[..]

Na das ist ja ein Ding. Das... ähm... macht mich ganz schön ratlos o_O.

Ich hätte da so ein paar Dinge, die ich gerne wüsste. Aber das wird jetzt nur anhand von Logs schwierig, da gehen mir echt die Ideen aus. Hast du SSH auf deine Box?

[uwec]

Ich hätte da so ein paar Dinge, die ich gerne wüsste. Aber das wird jetzt nur anhand von Logs schwierig, da gehen mir echt die Ideen aus. Hast du SSH auf deine Box?

Nein, habe keinen SSH Zugang (und habe es ehrlich gesagt auch nicht vor).
Denke wir können nur warten, ob ggf jemand anders auch noch einen Tip/Hinweis hat.

[okaegi]

Ganz eine dummy Frage und noch eine Idee zum prüfen:
Kannst du mal einen Printscreen von den Pv Einstellungen und deinen Speicher Einstellungen machen ?
Die Pv Zähler! Speicher Import / Export werden unter umständen von OpenWb gerechnet.
Für pv Solaredge (position 4 im Excel , in loadvars.sh circa Zeile 1075)
if [[ $speichermodul == "speicher_solaredge" ]] && [[ $pvwattmodul == "wr_solaredge" ]]; then
usesimpv=1
fi

Für Speicher (position 9 und 10, im excel (in loadvars.sh cirka Zeile 1165)

if [[ $speichermodul == "speicher_e3dc" ]] || [[ $speichermodul == "speicher_tesvoltsma

Die Solaredge pv Zähler sind mit angeschlossenener Batterie mit Vorsicht zu geniessen, da dies um 20:00 sich noch ändern. (Slave 1, energy=3585010*10^0, energy=3585012*10^0).
Und dann gehe ich nicht davon aus, dass bei dir noch die Sonne scheint...
Wenn openwb diese Zähler selber rechnet, wird der ausgelesene Zähler vom Solaredge Modul von Openwb überschrieben. Das würde erklären, warum der Zähler plötzlich bei 0 anfängt. Schau mal ob du in openwb.log so einen text findest
2021-12-11 15:46:13: loadvars read openWB/pv/WHExport_temp from mosquito
2021-12-11 15:46:09: loadvars read openWB/pv/WHImported_temp from mosquito
Gruss Oliver

[yankee]

Ganz eine dummy Frage und noch eine Idee zum prüfen:
Kannst du mal einen Printscreen von den Pv Einstellungen und deinen Speicher Einstellungen machen ?

Dafür hat uwec noch eine separaten Thread: viewtopic.php?f=9&t=4493

Die Pv Zähler! Speicher Import / Export werden unter umständen von OpenWb gerechnet.
Für pv Solaredge (position 4 im Excel , in loadvars.sh circa Zeile 1075)
if [[ $speichermodul == "speicher_solaredge" ]] && [[ $pvwattmodul == "wr_solaredge" ]]; then
usesimpv=1
fi

Du hast es gefunden! Du bist ein Held!

Leider ist das total bescheuert und funktioniert wie man sieht auch garnicht richtig. Denn das PV-Modul weiß davon nichts und schreibt trotzdem fröhlich seine Summe raus. Das wird dann hier vom Simcount überschrieben und es gibt eine Race-Condition: Mal gibt es den Wert, mal den anderen wert, je nachdem wer gerade schneller ist. Für das mqttsub-Programm ist wohl in aller Regel das PV-Modul schneller, für den 5-Min-Cron das Simcount. Und dann passt das logischerweise alles nicht zusammen.

Warum wurde das so gemacht? Wahrscheinlich weil es keinen Register gibt der die Gesamtenergie aus der Batterie misst? Sicher? Ist das so? Ich habe nirgends eine Doku gefunden in der steht welche Register es für die Batterie gibt. Vielleicht existiert sowas ja? Warum wurde dann das Schreiben vom Wert in im PV-Modul an der Stelle nicht ersetzt, damit es zu keiner Race-Condition kommt? Einfach vergessen? Absicht?

Eingefügt wurde das ganze in Commit 48f6d9a3b7f4bbe0625e37925b715711468a15f4. Der Kommentar von dem Commit ist "Eigene Wh Berechnung wenn PV & Speicher Solaredge gewählt ist". Kein Kommentar dazu warum das gemacht wurde. Kein Kommentar im Quelltext. Der Commit ist direkt auf Master, also gibt es auch kein PR dazu wo man mal nachlesen könnte was das eigentlich soll. Ob sich jemand was dabei gedacht hat oder "passt schon". Das möchte ich gerne am Rande als Apell nutzen: Wenn ihr was verändert, dann dokumentiert doch bitte auch den Grund. Jahre später kommen andere Leute und wundern sich über euren Code. Es ist blöd, wenn dazu nichts mehr auffindbar ist.

Also meine Lösung wäre entweder (und das wäre die bessere Lösung) Register zu finden mit denen man an Batterie-Export und -Import kommt oder Simcount zu nutzen, aber nicht an einer solch unintuitiven Stelle sondern im SolarEdge-Modul selbst und dann nur den erechneten Wert rausschreiben und nicht "mal so, mal so".

Erster Versuch: Register finden. Google hat mir das hier ausgespuckt: https://www.photovoltaikforum.com/core/ ... rters-pdf/

Bisher lesen wir als SoC den Register 62852 (=0xF584) aus. In dem Dokument steht auf Seite 20 genau dieser Register für "Battery 1 State of Energy (SOE)". Ein gutes Zeichen. Wenn das übereinstimmt, dann stimmen vielleicht auch die anderen Register. Demnach müssten wir mit dem Register 0xF576 an den Lifetime-Export und mit dem Register 0xF57A an den Lifetime-Import (beides Wattstunden als Uint64) kommen. Könnte das jemand überprüfen der eine Batterie hat und einmal diese Register manuell auslesen?

[okaegi]

Danke für die Blumen.
Bisher war es so das in loadvars.sh
So bei zeile 370 der Pv driver abgefragt wurde

if [[ $pvwattmodul != "none" ]]; then
pv1vorhanden="1"
echo 1 > /var/www/html/openWB/ramdisk/pv1vorhanden
pvwatt=$(modules/$pvwattmodul/main.sh || true)
if ! [[ $pvwatt =~ $re ]] ; then
pvwatt="0"
fi
pv1watt=$pvwatt
echo $pv1watt > ramdisk/pv1watt
else
pv1vorhanden="0"
echo 0 > /var/www/html/openWB/ramdisk/pv1vorhanden
pvwatt=$(</var/www/html/openWB/ramdisk/pvwatt)
fi

Und dann der Speicher Werte bei 493
#Speicher werte
if [[ $speichermodul != "none" ]] ; then
timeout 5 modules/$speichermodul/main.sh
if [[ $? -eq 124 ]] ; then
openwbModulePublishState "BAT" 2 "Die Werte konnten nicht innerhalb des Timeouts abgefragt werden. Bitte Konfiguration und Gerätestatus prüfen."
fi


Und nacher dann ggf simcount bei 1000 genutzt um die Zähler neu zu rechnen.
Kann es vielleicht sein, dass durch die neue Driverstruktur der Wr nicht mehr synchron abgefragt wird ?
Dann könnte das von dir beschriebene Verhalten erklärt werden.

Ich würde folgendes mal anregen (radikaler Vorschlag):
Warum fahren wir nicht für alle Speicher, Bezugszähler und Wr grundsätzlich mit Simcount für alle Grafiken und csv logs und lesen eventuell vorhanden Zähler separat aus für den Status und speichern diese als seperate Spalten in csv ohne mit ihnen zu rechnen ? Ladestationen würde ich nur mit Hw Zähler fahren wegen dem Steueramt.
Wir haben wr:
a) Die Zähler anders rechnen (Wr mit Batterie, manche Hersteller rechnen z.b. Batterladung aus Pv nicht auf den Pv Zähler )
b) Die keine Zähler haben
c) Wenn ein Wr ausgetauscht wird ist der Zähler futsch.
.
Vorteile:
Damit würden die Basisrechnungen/logs in Openwb für neue Wr auf Anhieb funktionieren.
Wir sparen uns ein Haufen komplexer Abfragen im loadvars.sh wann wir simcount brauchen und wann nicht.
Die Hw Zähler hätten wir dann als separate Attribute abgespeichert.
Die csv Dateinen könnten wir auch rückwirkend erweitern (csvcalc), wir müssten uns dann nur klar werden, ob wir wie heute nur einen Wr Zähler nehmen, oder z.b. maximal 8 Wr (8 Speicher) unterstützen wollen

Und noch was zusätzliches:
Der Tagesertrag wird heute schon von openwb aufgrund der gelesen Zähler / Simcount Zähler gerechnet
Ich habe einen Pr gemacht
https://github.com/snaptec/openWB/pull/1798
Um den Monatszähler und den Jahresertrag ebenso durch openwb rechnen zu lassen.
Einige wenige Wr liefern bereits diese Werte, aber nicht alle.
.
Gruss Oliver

[yankee]

Ich würde folgendes mal anregen (radikaler Vorschlag):
Warum fahren wir nicht für alle Speicher, Bezugszähler und Wr grundsätzlich mit Simcount für alle Grafiken und csv logs und lesen eventuell vorhanden
Zähler separat aus für den Status und speichern diese als seperate Spalten in csv ohne mit ihnen zu rechnen ?

Bitte nicht. Das ist ungenau und Fehler können sich akkumulieren. Schon wenn alles stabil läuft ist Simcount nur eine Annäherung. Die Annäherung ist umso besser je kleiner die Abtastrate ist. Aktuell ist die Abtastrate meistens bei 10 Sekunden, dass dürfte in den meisten Fällen schon eine sehr gute Annäherung sein, aber trotzdem bleibt es eine Annäherung. Ganz daneben liegt es wenn die Abtastrate runter geht. Zum Beispiel weil ein Netzwerkfehler vorliegt und der Zähler über einen gewissen Zeitraum nicht ausgelesen werden kann. Dann ist alles daneben.

Wir haben wr:
a) Die Zähler anders rechnen (Wr mit Batterie, manche Hersteller rechnen z.b. Batterladung aus Pv nicht auf den Pv Zähler )

Das ist bei der Leistung genau so und das Problem geht damit nicht weg. Schlimmer noch: Wenn jemand bei der Leistung was falsch macht, dann akkumuliert sich ein großer Fehler wenn die Energie auf der Basis mit simcount gerechnet wird.

b) Die keine Zähler haben

Ja, in dem Fall bleibt einem nichts anderes übrig. Allerdings... Welcher Zähler hat denn heutzutage keinen Ertragszähler? Bei älteren WR mag das ja sein, aber das ist dann ein aussterbendes Phänomen? Der Fronius Gen24 soll wohl erst mit Firmware 1.13.13-1 seinen Zähler in die API bekommen haben. Schon was dämlich von Fronius, fein, aber doch hoffentlich eine seltene Ausnahme?

c) Wenn ein Wr ausgetauscht wird ist der Zähler futsch.

Wann sowas erhalten bleiben soll, dann braucht es eben ein "offset", in dem der Startwert vom Zähler festgehalten wird. Dann kann man stets den offset Wert auf den neuen Wert dazu addieren. Der offset würde dann nur einmalig gesetzt werden beim Zählertausch und würde dann immer so bleiben.

Und noch was:
Der Tagesertrag wird heute schon von openwb aufgrund der gelesen Zähler / Simcount Zähler gerechnet.

Das ist ein großer Unterschied ob der Tagesertrag auf Basis von gelesener Energiezähler oder auf Basis mathematisch integrierter Leistung gerechnet wird. Also Tagesertrag aus der Differenz zwischen zwei Zählerständen zu rechnen ist ein nahezu idiotensicheres Verfahren (ich weiß: Der größte Fehler von Leute die versuchen etwas absolut idiotensicheres zu designen ist es den Einfallsreichtum von absoluten Idioten zu unterschätzen ). Ein Integral basierend auf einer Abtastung ist nur eine Annäherung.

Damit würden die Basisrechnungen/logs in Openwb für neue Wr auf Anhieb funktionieren.

Unter der Vorraussetzung, dass die Leistung korrekt implementiert ist. Wenn man das mit der Leistung geschafft hat ist das mit der Energie auch nurnoch ein kleiner Schritt.

Wir sparen uns ein Haufen komplexer Abfragen im loadvars.sh wann wir simcount brauchen und wann nicht.

Die kann man sich auch so da sparen. Was machen diese Abfragen da?! Wenn man meint man braucht das kann man das doch im Modul selbst aufrufen.

Die Hw Zähler hätten wir dann als separate Attribute abgespeichert.

Wo ist der Vorteil davon "dass man es sich sparen kann die HW-Zähler auszulesen", wenn man die HW-Zähler doch ausliest und speichert? Dann hast du nicht anderes gewonnen als einen weiteren Datensatz, der falsch sein kann und über den man sich wundert.

[openWB]

Ja, in dem Fall bleibt einem nichts anderes übrig. Allerdings... Welcher Zähler hat denn heutzutage keinen Ertragszähler? Bei älteren WR mag das ja sein, aber das ist dann ein aussterbendes Phänomen? Der Fronius Gen24 soll wohl erst mit Firmware 1.13.13-1 seinen Zähler in die API bekommen haben. Schon was dämlich von Fronius, fein, aber doch hoffentlich eine seltene Ausnahme?

Gerade bei Hybrid Systemen ist das eher die Regel als die Ausnahme.

E3DC, Tesvolt, Solarwatt, RCT, LG, Plenticore, Powerwall, SolarEdge, Sonnen, Varta.
Hinzu kommt die Aufteilung ob/was dann nur DC und oder AC ist.

Das ist ein großer Unterschied ob der Tagesertrag auf Basis von gelesener Energiezähler oder auf Basis mathematisch integrierter Leistung gerechnet wird. Also Tagesertrag aus der Differenz zwischen zwei Zählerständen zu rechnen ist ein nahezu idiotensicheres Verfahren (ich weiß: Der größte Fehler von Leute die versuchen etwas absolut idiotensicheres zu designen ist es den Einfallsreichtum von absoluten Idioten zu unterschätzen ). Ein Integral basierend auf einer Abtastung ist nur eine Annäherung.

Die eigene Berechnung erzeugt den Zählerstand. Tagesertrag / Graphen basierend dann auf Deltas davon.

Übrigens ist die Simcount Variante erstaunlich genau. Zumindest genauer als so manche Zählung die von den Herstellern fabriziert wird. MID steht da ohnehin nirgends drauf. Das haben nur wir in den Ladepunkten und hier wird ohnehin mit dem ausgelesenen Zählerstand gearbeitet.

Unter der Vorraussetzung, dass die Leistung korrekt implementiert ist. Wenn man das mit der Leistung geschafft hat ist das mit der Energie auch nurnoch ein kleiner Schritt.

Sollte man meinen, ist aber oft nicht der Fall.
z.B. wenn die Leistung für PV / Speicher aufgeschlüsselt ist, der Hybrid WR dann aber nur einen Zähler für die AC Erzeugung hat. Schwups zählt der nachts die PV Erzeugung hoch obwohl die Batterie entladen wird.

Wo ist der Vorteil davon "dass man es sich sparen kann die HW-Zähler auszulesen", wenn man die HW-Zähler doch ausliest und speichert? Dann hast du nicht anderes gewonnen als einen weiteren Datensatz, der falsch sein kann und über den man sich wundert.

Da bin ich bei dir. Entweder die aaslesbaren Zählerstände sind plausibel und nutzbar oder man kann sie gleich vergessen.

[yankee]

E3DC, Tesvolt, Solarwatt, RCT, LG, Plenticore, Powerwall, SolarEdge, Sonnen, Varta.

In der SolarEdge-Doku steht zumindest ein Register mit dem sich die Zähler seperat auslesen lassen. Noch haben wir es zwar nicht getestet aber aktuell steht zumindest im Raum, dass es den Zähler gibt. Powerwall habe ich vor kurzem überarbeitet weil es kaputt war. Die Auszüge aus der API die mir ein Nutzer geschickt hat zeigen separate Werte für Batteriezähler. Wird halt von der oWB nicht ausgelesen.

Mit den anderen Modulen hatte ich noch keinen Kontakt, aber würde mich jetzt nicht wundern wenn sich meine Strähne so fortsetzt.

Hinzu kommt die Aufteilung ob/was dann nur DC und oder AC ist.

Klar, das muss man bei Hybridsystemen auch noch bedenken. Muss man bei der Leistung allerdings auch...

Die eigene Berechnung erzeugt den Zählerstand. Tagesertrag / Graphen basierend dann auf Deltas davon.

Richtig. Deltas zu nehmen vom Zählerstand finde ich sinnvoll. Das ist einfach, nachvollziehbar und robust. Den Zählerstand durch Berechnung zu erzeugen finde ich nicht sinnvoll, wenn ein "richtiger" Zählerstand zur Verfügung steht.

Übrigens ist die Simcount Variante erstaunlich genau. Zumindest genauer als so manche Zählung die von den Herstellern fabriziert wird.

Wie hast du das festgestellt? Da die Berechnung auf der Leistung basiert die von dem selben Zähler kommt, kann der errechnete Zähler eigentlich nicht besser sein, als der abgerufene.

Wie schon erwähnt: Solange die Abtastrate hoch genug ist, wird es in normalen Haushalten mit der Genauigkeit von Simcount gut hinkommen. Es sei denn es kommt was dazwischen. Der erwähnte Ausfall des Netzwerks zum Beispiel. Dann ist alles hinüber. Mit Glück passiert das nie. Wenn doch ist eben schade.

Daneben erzeugt das auch wieder Supportaufwand, weil die Leute sich dann wundern, dass die Zähler vom Hersteller nicht mit den Zählern aus der openWB übereinstimmen.

Ich will auch garnicht sagen, dass man Simcount nicht verwenden soll oder das ganze System nichts taugt. Es ist sehr gut, dass das Simcount-Modul da ist um solche Geräte zu unterstützen, die keinen Zähler haben. Es ist auch einfach hinzuzufügen. Man muss nur im Modul welches es braucht Simcount aufrufen und schon hat man den Wert drin. Ich stelle mich nur gegen den Vorschlag den Modulen das Simcount aufzuzwingen und die Möglichkeit die Zähler auszulesen zu nehmen.

[openWB]

Wie hast du das festgestellt? Da die Berechnung auf der Leistung basiert die von dem selben Zähler kommt, kann der errechnete Zähler eigentlich nicht besser sein, als der abgerufene.

Im Vergleich bei Anlagen die einen WR haben und zusätzlich einen MID geeichten Zähler vor dem WR und zusätzlich Simcount.
Simcount war hier oft näher am MID geeichten Zähler als der Wechselrichter selbst.
Ich nenne allerdings keine Namen welche Wechselrichterhersteller hier getestet wurden.

Wie schon erwähnt: Solange die Abtastrate hoch genug ist, wird es in normalen Haushalten mit der Genauigkeit von Simcount gut hinkommen. Es sei denn es kommt was dazwischen. Der erwähnte Ausfall des Netzwerks zum Beispiel. Dann ist alles hinüber. Mit Glück passiert das nie. Wenn doch ist eben schade.

Eine openWB ohne Netzwerk ist mit das einzig unschöne, das stimmt.

Ich will auch garnicht sagen, dass man Simcount nicht verwenden soll oder das ganze System nichts taugt. Es ist sehr gut, dass das Simcount-Modul da ist um solche Geräte zu unterstützen, die keinen Zähler haben. Es ist auch einfach hinzuzufügen. Man muss nur im Modul welches es braucht Simcount aufrufen und schon hat man den Wert drin. Ich stelle mich nur gegen den Vorschlag den Modulen das Simcount aufzuzwingen und die Möglichkeit die Zähler auszulesen zu nehmen.

Wenn es "einfach" den Zählerstand gibt bin ich da voll bei dir

[uwec]

Bisher lesen wir als SoC den Register 62852 (=0xF584) aus. In dem Dokument steht auf Seite 20 genau dieser Register für "Battery 1 State of Energy (SOE)". Ein gutes Zeichen. Wenn das übereinstimmt, dann stimmen vielleicht auch die anderen Register. Demnach müssten wir mit dem Register 0xF576 an den Lifetime-Export und mit dem Register 0xF57A an den Lifetime-Import (beides Wattstunden als Uint64) kommen. Könnte das jemand überprüfen der eine Batterie hat und einmal diese Register manuell auslesen?

Ich konnte die Register noch nicht auslesen, allerdings kann ich bestätigen, dass dein SOC Register 62852 (=0xF584), den du ausliest und ins Debug-Log schriebst, korrekt ist.
Entsprechend deiner Quelle von Solaredge würde ich die Register 0xF576 an den Lifetime-Export und mit dem Register 0xF57A an den Lifetime-Import (beides Wattstunden als Uint64) auch so sehen.