Photovoltaik Eigenverbrauch,Bilanz,Prognose (Kostal Plenticore; KSEM; BYD HV)

[andi11]

dann bau ich mal wieder zurück. Hat das eigentlich einen speziellen Grund dass die Config in Readings gespeichert wird und nicht in attributen? Dann wäre die Modulconfig in der fhem.cfg

[ch.eick]

dann bau ich mal wieder zurück. Hat das eigentlich einen speziellen Grund dass die Config in Readings gespeichert wird und nicht in attributen? Dann wäre die Modulconfig in der fhem.cfg

Da habe ich zuwenig kenntnisse über die einzelnen Module. Kann ich einfach eigene Attribute in einem fremden Modul erstellen?
Für mich ist das WR_1_config ein Device um die Parameter zu sammeln und diese im GUI einfach zu verändern.
Beim WR_1_Speicher_1_ExternControl oder Kia_eNiro_PV wird ja eh ein DOIF verwendet, bei dem ich das dann über uiTable erledigt habe.
Führt nicht auch die Änderung von Attributen dazu, dass man jedesmal ein "Save config" machen müsste?

Solltest Du da bessere Kenntnisse haben, dann wäre ich sehr erfreut.

Diese PV-Anlagen Implementierung ist kein Modul, es bedient sich nur bei den anderen Modulen, damit der Support etwas weiter gestreut wird.

[andi11]

Eine Änderung von Attributen macht ein Save Config nötig. Aber wie oft ändert man im WR_Config device dass dies ein Nachteil wäre?. Allerdings ist damit die Konfiguration auch direkt in der fhem.cfg gesichert. Bei Setreading/setstate ist die Konfiguration nicht automatisch gleich gesichert.
Ich mache z.b. täglich ein Backup der fhem.cfg. Da wäre es schön, wenn solche Änderungen mit archiviert werden, um im Bedarfsfall drauf zugreifen zu können.

Um eigene Atribute zu erstellen gibt es das Attribut userattr. Sobald da ein Parameter erstellt wurde, taucht es normal in der Attributsliste zum auswählen oder für Direkteingabe auf. Man muss nicht gleich ein Modul erstellen, nur weil man Attribute verwendet.

Edit3: Kleiner Einwand noch bezgl. zeitlichem Offset zwischen Forecast und Istwert. Den muss es ja geben um 8Uhr wird der Wert der nächsten Stunde berechnet. Der Istwert ist aber in der aktuellen Stunde => zum direkten Vergleich und anpassen muss das ganze um eine Stunde versetzt betrachtet werden

Edit: Was machst du aktuell mit den Daten aus der Prognose? Zum steuern der Verbraucher verwendest du Total_PV_Power_reserve, aber das wird nirgends erstellt. Vermutlich fehlt mir hier nur ein kleiner Zwischenteil da ich ja kein Kostalgerät habe.

Edit2: Aktuell wird in der Berechnung der fc1 Wert mit dem Timestamp von morgen in der Datenbank abgespeichert. Also wird gerade im Moment im SVG dargestellt:
FC0 => Vorhersage von heute für heute
FC1 => Vorhersage von gestern für heute
Ist es nicht logischer den Forcecast Wert von morgen heute anzuzeigen? Also vom Timestamp einen Tag abziehen, wenn ein fc1 Wert berechnet wird? Ich korrigiere das momentan mit dem logproxy:

Code Auswählen Erweitern

#lp DbLog:logdb,offset=60*60*-24:DUMMY_PV:Solar_Calculation_fc1

[ch.eick]

Eine Änderung von Attributen macht ein Save Config nötig. Aber wie oft ändert man im WR_Config device dass dies ein Nachteil wäre?. Allerdings ist damit die Konfiguration auch direkt in der fhem.cfg gesichert. Bei Setreading/setstate ist die Konfiguration nicht automatisch gleich gesichert.
Ich mache z.b. täglich ein Backup der fhem.cfg. Da wäre es schön, wenn solche Änderungen mit archiviert werden, um im Bedarfsfall drauf zugreifen zu können.

Um eigene Atribute zu erstellen gibt es das Attribut userattr. Sobald da ein Parameter erstellt wurde, taucht es normal in der Attributsliste zum auswählen oder für Direkteingabe auf. Man muss nicht gleich ein Modul erstellen, nur weil man Attribute verwendet.

Das schaue ich mir dann später mal an

Edit3: Kleiner Einwand noch bezgl. zeitlichem Offset zwischen Forecast und Istwert. Den muss es ja geben um 8Uhr wird der Wert der nächsten Stunde berechnet. Der Istwert ist aber in der aktuellen Stunde => zum direkten Vergleich und anpassen muss das ganze um eine Stunde versetzt betrachtet werden

Mir war es einfach nur wichtig, dass die Prognose mit der realität deckungsgleich ist.
Beim DWD werden die rad1h Werte für 8:00 Uhr auch erst mit 9:00 Uhr angegeben, also zum Ende der Stunde.
Bei mir war es auch viel Ausprobieren, bis es gepasst hat.

Edit: Was machst du aktuell mit den Daten aus der Prognose? Zum steuern der Verbraucher verwendest du Total_PV_Power_reserve, aber das wird nirgends erstellt. Vermutlich fehlt mir hier nur ein kleiner Zwischenteil da ich ja kein Kostalgerät habe.

Der Total_PV_Power_reserve Wert ist ein userreading im WR_1 und berücksichtigt, dass ich z.B. einen Verbraucher einschalten kann, auch wenn aktuell der Speicher geladen wird. Das ist in der Übergangszeit und bei wenig Leistung wichtig. Ich versuche immer zuerst einen sofort Verbrauch, bevor der Speicher geladen wird. Der Speicher soll immer nut die Reste bei schlechtem Wetter ( Winter ) aufsammeln.

Edit2: Aktuell wird in der Berechnung der fc1 Wert mit dem Timestamp von morgen in der Datenbank abgespeichert. Also wird gerade im Moment im SVG dargestellt:
FC0 => Vorhersage von heute für heute
FC1 => Vorhersage von gestern für heute

Das ist zum Vergleich, wie gut der Vorcast von gestern für heute gewesen ist. Der DWD aktualisiert ja die Daten alle paar Stunden.

Ist es nicht logischer den Forcecast Wert von morgen heute anzuzeigen? Also vom Timestamp einen Tag abziehen, wenn ein fc1 Wert berechnet wird? Ich korrigiere das momentan mit dem logproxy:

Code Auswählen Erweitern

#lp DbLog:logdb,offset=60*60*-24:DUMMY_PV:Solar_Calculation_fc1

Das kannst Du gerne so machen, ich schaue mir den Graphen nur sehr selten im Grafana an und da kann ich das Datum von Morgen einfach einstellen.
Die Abfrage auf bestimmte Werte ist ja über das WR_1 Device möglich, was dann zur Steuerung verwendet wird.
Auch über die Datenbank könnte man auch wieder direkt auf die Werte lesend zugreifen.

Gruß
   Christian

[andi11]

Mir war es einfach nur wichtig, dass die Prognose mit der realität deckungsgleich ist.
Beim DWD werden die rad1h Werte für 8:00 Uhr auch erst mit 9:00 Uhr angegeben, also zum Ende der Stunde.
Bei mir war es auch viel Ausprobieren, bis es gepasst hat.

Wie sollte es per Definition sein?
Solar_Calculation um 12Uhr beschrieben => Erzeugung für 12-13Uhr oder von 11-12Uhr?
Solar_Calculation_fc0_12 um 12 Uhr beschrieben=> Erzeugung für 12-13Uhr oder von 11-12Uhr?

Rad1h vom DWD ist für die letzte Stunde, du arbeitest aber mit einem Timeshift von einer Stunde. 

[ch.eick]

Wie sollte es per Definition sein?
Solar_Calculation um 12Uhr beschrieben => Erzeugung für 12-13Uhr oder von 11-12Uhr?

Das sind wh um 12 Uhr.
Annäherungsweise setze ich dann in der Zeit von 12 - 13 Uhr auch als kWh, weil es ja genau eine Stunde ist.

Solar_Calculation_fc0_12 um 12 Uhr beschrieben=> Erzeugung für 12-13Uhr oder von 11-12Uhr?

Das sollte der selbe Wert sein, es ist Leistung und nicht Energie in kWh!

Rad1h vom DWD ist für die letzte Stunde, du arbeitest aber mit einem Timeshift von einer Stunde.

Wie ich geschrieben habe ist die Definition beim DWD, das der Wert der Strahlung zum Ende der Stunde angegeben wird. Deshalb habe ich den Timeshift gemacht und bei mir hat es dann gepasst.

Ich verstehe im Moment nicht was Du jetzt für ein Problem hast. Deine Kurven waren von Mittags bis abends deckungsgleich, besser geht es nicht.
Morgens hatte ich geschrieben, dass Du die Prognose durch Solar_plain() auf 0,0001 auf Null ziegehen solltest. Das die Prognose am Vormittag über der realität liegt, liegt an der Überschwenglichen Prognose des DWD, was bei mir auch der Fall ist. Somit sehen Deine Kurven super aus, oder Du erklärst bitte nochmal, was nicht passt.

Wenn Du es für notwendig hällst könntest Du noch den forecast_factor auf z.B. 0.9 setzen, dann gehen alle Werte des Tages auf 90 %, aber auch am Nachmittag. Du solltest es aber einfach beobachten und das über einen kompletten Jahres Zyklus, denn es soll ja auch zu anderen Zeiten passen. Der goldene Mittelweg ist der richtige, die Zielsetzung liegt nicht darin eine exakte Prognose von XX kWh am Tag zu bekommen, sondern zum richtigen Zeitpunkt einen Trigger zu haben, um die großen Langzeitverbraucher zu schalten.

VG
   Christian

[ch.eick]

Moin zusammen.
Bald ist Sommer noch einmal weniger Heizen und der Accu schafft es durch die Nacht...

Sonnige Grüße
   Christian

[andi11]

Ich habe meine Module über module_direction solange gedreht bis Solar_Calculation Deckungsgleich mit der Istwertberechnung war.
Würde nur gerne rausfinden ob dieser Ansatz überhaupt korrekt ist.
=> Ich will verhindern dass ich bei meiner Anpassung übers Jahr die falschen Werte vergleiche.

[ch.eick]

Ich habe meine Module über module_direction solange gedreht bis Solar_Calculation Deckungsgleich mit der Istwertberechnung war.
Würde nur gerne rausfinden ob dieser Ansatz überhaupt korrekt ist.
=> Ich will verhindern dass ich bei meiner Anpassung übers Jahr die falschen Werte vergleiche.

Durch das Verdrehen hast Du generell eine falsche Prognose.

Lies einfach nochmal diesen post
Ich verstehe Dein Problem einfach nicht mehr? Es ist normal, dass die Prognose nicht 100% ist.
Du bist auch noch nicht bei der Autokorrektur angekommen.
An anderen Tagen wird es noch viel gravierendere Abweichungen geben, gerade wenn noch Wolken und Regen dazu kommen, wie im Bild.

[andi11]

Ich hatte die Deckungsgleichheit nur durch das verdrehen der Module erreicht, und genau das will ich aber nicht.
Daher eben die spezifische Frage welcher Wert was genau bedeutet. Jetzt weiß ich dass der Forecast_12 den Wert von 12-13Uhr anzeigt, und das kann ich entsprechend um 13Uhr mit der Erzeugung vergleichen und korrigieren

[ch.eick]

Ich hatte die Deckungsgleichheit nur durch das verdrehen der Module erreicht, und genau das will ich aber nicht.
Daher eben die spezifische Frage welcher Wert was genau bedeutet. Jetzt weiß ich dass der Forecast_12 den Wert von 12-13Uhr anzeigt, und das kann ich entsprechend um 13Uhr mit der Erzeugung vergleichen und korrigieren

Nein, das ist die Erwartete Leistung um 12 Uhr in Watt. Wenn Du die Zeit ins Spiel bringst wären es kWh, was hier aber nicht der Fall ist.
Um z.B. 12:10 könnten auch 500 Watt mehr sein, das gibt aber der rad1h Wert vom DWD nicht her. Schau Dir mal mein letztes Bild an, dann verstehst Du was ich meine.
Nur eine Wolke und das ganze bricht eventuell drastisch ein.

Ich verstehe immer noch nicht, was Du erreichen möchtest?

[andi11]

Nein, das ist die Erwartete Leistung um 12 Uhr in Watt. Wenn Du die Zeit ins Spiel bringst wären es kWh, was hier aber nicht der Fall ist.
Um z.B. 12:10 könnten auch 500 Watt mehr sein, das gibt aber der rad1h Wert vom DWD nicht her. Schau Dir mal mein letztes Bild an, dann verstehst Du was ich meine.
Nur eine Wolke und das ganze bricht eventuell drastisch ein.

Ich verstehe immer noch nicht, was Du erreichen möchtest?

Mir geht es nicht um Wolken und andere Leistungskiller. Im ersten Moment nur perfekte Sonnentage.
Das erklärt deine Verwirrung und mein Unverständnis.

Für mich war in dem Fall zwischen Watt und Wh kein Unterschied, solange dass Zeitraster eine Stunde ist.
Rad1h habe ich beim DWD als "Strahlung letzte Stunde" verstanden. Da ist die Einheit kJ/m² => Im ersten Moment kann damit durch Umrechnung Wh berechnen, aber keine Watt.

=> Meine Schlussfolgerung: Um 12Uhr gilt folgendes:
Durch den Offset von 1 aus deiner Funktion wird der fc0_13_rad1h Wert vom DWD für die fc0_12 Berechnung verwendet. Damit beinhaltet fc0_12 aus deinem Forcecast kwh Erzeugung von 12-13Uhr.
Damit ist die korrekte Vergleichsgröße nicht die aktuelle Erzeugung vom Wechselrichter sondern "Erzeugung in der letzten Stunde". Um 12Uhr wäre das Zeitraum 11-12Uhr. Das ist aber der falsche Zeitraum, es müsste mit 12-13Uhr verglichen werden.

=> Um den 12Uhr Forecast Wert (12-13Uhr) mit der Erzeugung (12-13Uhr) im Chart zu vergleichen muss die Erzeugung um eine Stunde in die Vergangenheit verschoben werden.

Mein Vergleichchart ist damit aktuell so aufgebaut. in statTotal-get habe ich vom statistics Modul stunden, tages und monatswerte der Erzeugung.

Code Auswählen Erweitern



#logdb DUMMY_PV:Solar_Haus:::$val=$val/1000
#logdb DUMMY_PV:Solar_GartenHaus:::$val=$val/1000
#lp DbLog:logdb,offset=60*60*-1:Stromverbrauch_Zaehler3:statTotal-get:::$val=~s/.*Hour..(([\d]*.[\d]*)|[\d]*).*/$1/e
#lp DbLog:logdb,offset=60*60*-1:Stromverbrauch_Zaehler4:statTotal-get:::$val=~s/.*Hour..(([\d]*.[\d]*)|[\d]*).*/$1/e
plot
"<IN>" using 1:2 axes x1y1 title 'calc-Hausdach' ls l7 lw 1 with lines,\
"<IN>" using 1:2 axes x1y1 title 'calc-Gartenhaus' ls l7 lw 1 with lines,\
"<IN>" using 1:2 axes x1y1 title 'Haus' ls l0 lw 1 with lines,\
"<IN>" using 1:2 axes x1y1 title 'GartenHaus' ls l1 lw 1 with lines

Stimmt das so? Chart von gestern (bestes PV Wetter) im Anhang. Allerdings gelten nur die Maximalwerte pro Stunde vom Sägezahn. Dabei hab ich die Moduldrehung von 7Grad wieder 0 gesetzt. (laut Sonnenverlauf.de sollten es -2Grad sein)

Deine vorangegangen Posts habe ich mehrfach gelesen, konnte aber keine Ursache für meine Abweichung finden und hatte insofern die Module gedreht. Was aber keine wirklich schöne Lösung ist

[ch.eick]

Mir geht es nicht um Wolken und andere Leistungskiller. Im ersten Moment nur perfekte Sonnentage.
Das erklärt deine Verwirrung und mein Unverständnis.

Für mich war in dem Fall zwischen Watt und Wh kein Unterschied, solange dass Zeitraster eine Stunde ist.
Rad1h habe ich beim DWD als "Strahlung letzte Stunde" verstanden. Da ist die Einheit kJ/m² => Im ersten Moment kann damit durch Umrechnung Wh berechnen, aber keine Watt.

=> Meine Schlussfolgerung: Um 12Uhr gilt folgendes:
Durch den Offset von 1 aus deiner Funktion wird der fc0_13_rad1h Wert vom DWD für die fc0_12 Berechnung verwendet. Damit beinhaltet fc0_12 aus deinem Forcecast kwh Erzeugung von 12-13Uhr.
Damit ist die korrekte Vergleichsgröße nicht die aktuelle Erzeugung vom Wechselrichter sondern "Erzeugung in der letzten Stunde". Um 12Uhr wäre das Zeitraum 11-12Uhr. Das ist aber der falsche Zeitraum, es müsste mit 12-13Uhr verglichen werden.

=> Um den 12Uhr Forecast Wert (12-13Uhr) mit der Erzeugung (12-13Uhr) im Chart zu vergleichen muss die Erzeugung um eine Stunde in die Vergangenheit verschoben werden.

Mein Vergleichchart ist damit aktuell so aufgebaut. in statTotal-get habe ich vom statistics Modul stunden, tages und monatswerte der Erzeugung.

Code Auswählen Erweitern


< snip>


Stimmt das so? Chart von gestern (bestes PV Wetter) im Anhang. Allerdings gelten nur die Maximalwerte pro Stunde vom Sägezahn. Dabei hab ich die Moduldrehung von 7Grad wieder 0 gesetzt. (laut Sonnenverlauf.de sollten es -2Grad sein)

Deine vorangegangen Posts habe ich mehrfach gelesen, konnte aber keine Ursache für meine Abweichung finden und hatte insofern die Module gedreht. Was aber keine wirklich schöne Lösung ist

Das hört sich ziemlich plausiebel an. Sollten in der Solar_forecast() fehler drin sein, so könntest Du das gerne überarbeiten. Ich hatte da eher den pragmatischen Ansatz und lasse mich gerne aufklären Für mich war es genug, dass die Prognose recht gut an die Realität ran reichte und ich habe sicher einige mathematische Fehler gemacht. Zu Beginn konnte ich sehen, dass es da eine Verschiebung um eine Stunde gegeben hat, also habe ich die Berechnung verschoben
Mit dem rad1h, kJ/m2 und Wh hast Du natürlich vollkommen recht, da ist wohl etwas durcheinander. Durch das Raster von 1 h ist mir das gar nicht so aufgefallen.
Der Sägezahn gefällt mir in solch einem Diagramm allerdings nicht so wirklich, wobei die Darstellung natürlich richtig ist.
Wenn Du also wert auf den Wh Vergleich legst musst Du natürlich die Watt des WR über die Zeit (bei mir im Minuten Rythmus) berechnen und diese dann mit der Prognose vergleichen. Bei dieser Aktion wäre dann auch die Berechnung der Gesamt Prognose, nächste vier Stunden und Rest des Tages zu korrigieren. Da habe ich auch einfach die Einzelwerte summiert und nicht die geometrische Fläche, wodurch das Ergebnis um ca 5-10% zu hoch ausfällt, was an der Steilheit der PV-Kurve liegt. Im Winter passt es besser.

Resüme:
Wenn Du Dich da mit einbringen möchtest, wäre ich ziemlich begeistert. Für die reine Steuerung der Eigenleistung ist es allerdings nicht erforderlich eine warscheinlich recht komplexe Überarbeitung zu machen. Die wenigsten besitzen überhaupt die erforderlichen Verbrauchsgeräte, die eine solche Steuerung notwendig machen.

Vielen Dank für Deine Analyse
    Christian

[andi11]

Resüme:
Wenn Du Dich da mit einbringen möchtest, wäre ich ziemlich begeistert. Für die reine Steuerung der Eigenleistung ist es allerdings nicht erforderlich eine warscheinlich recht komplexe Überarbeitung zu machen. Die wenigsten besitzen überhaupt die erforderlichen Verbrauchsgeräte, die eine solche Steuerung notwendig machen.

Werde mich da gerne mit einbringen. Allerdings sehe ich keine Notwendigkeit einer "recht komplexen Überarbeitung". Das Ergebniss an sich finde ich schon sehr gut wenn die Toleranz übers Jahr bei <20% liegt. Ich bin auch erst genauer in die Analyse eingestiegen als ich diesen zeitlichen Offset bei mir bemerkt hatte. Eigentlich müsstest du den aber auch haben, du hast ihn über den Offset im Script korrigiert, ist in Wirklichkeit vielleicht deine Anlage verdreht?

Die (bei mir noch nicht aktivierte) Autokorrektur wird hier einiges glätten können.
Das mit der Flächenberechnung verstehe ich zwar, glaube aber dass du das schon ausreichend berücksichtig hast. Rad1h liefert geometrisch gesehen schon ein Rechteck und mittelt über eine Stunde.

P.S.: Stimmt, Sägezahn ist hässlich

[ch.eick]

Werde mich da gerne mit einbringen. Allerdings sehe ich keine Notwendigkeit einer "recht komplexen Überarbeitung". Das Ergebniss an sich finde ich schon sehr gut wenn die Toleranz übers Jahr bei <20% liegt. Ich bin auch erst genauer in die Analyse eingestiegen als ich diesen zeitlichen Offset bei mir bemerkt hatte. Eigentlich müsstest du den aber auch haben, du hast ihn über den Offset im Script korrigiert, ist in Wirklichkeit vielleicht deine Anlage verdreht?

Die Verschiebung war durch den Versatz beim DWD, das der Wert der Stunde erst zum Ende der Stunde eingetragen wird. Warum das so ist verstehe ich selber nicht, da es ja eine Prognose ist, aber so sei es halt.

Die (bei mir noch nicht aktivierte) Autokorrektur wird hier einiges glätten können.

Das ist eh böser Woodo Zauber und ein reiner Versuch einen Korrekturfaktor zu ermitteln. Momentan habe ich das abgeschaltet, da die Werte bisher passen. Es kann ja auch sein, das der DWD besser geworden ist

Das mit der Flächenberechnung verstehe ich zwar, glaube aber dass du das schon ausreichend berücksichtig hast. Rad1h liefert geometrisch gesehen schon ein Rechteck und mittelt über eine Stunde.

P.S.: Stimmt, Sägezahn ist hässlich

Ich hatte ja Watt und Wh durcheinander gebracht. Im Ergebnis konnte ich aber erkennen, dass die Prognose ca 10% höher ist als der tatsächlich erzeugte yield am Tages Ende.
Im Moment habe ich einfach im stateFormat den Wert mit 0.9 multipliziert. Pragmatisch halt Ich berechne aber auch nichts weiter mit den prognose Werten, es ist nur ein Trigger/Schwellwert für die Eigenverbrauchssteuerung.