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

[ch.eick]

Wie ich sehe hast Du auch noch die WB_1 Steuerung weiter ausgebaut, hab ich auch mal mit übernommen und für den go-eCharger angepasst.
Testen kann ich das jetzt nur nicht wegen zu wenig Sonne.

Im Winter lade ich alles mit Sofortladen, da eh nicht genug PV Kommt und das dann durch den Hausspeicher aufgenommen würde.
Im WR_1_Speicher_1_ExternControl gab es nur änderungen bei der smart_Laden Umschaltung, das kannst Du auch mit den Sofortladen testen.

[ch.eick]

Hallo zusammen,
ich arbeite gerade an einem Device zur Erfassung der externen Ladeleistung für das BEV. Man hat ja nicht nur die Ladung an der eigenen Ladesäule
Falls Ihr dazu eigenen Ideen oder Anregungen habt wäre jetzt der geeignete Zeitpunkt.

Folgendes ist die Idee:

Code Auswählen Erweitern


- Das Device wird WB_0 heißen
- Man muss den TIMESTAMP für die Datenbank eingeben können
- Es kann mehrere BEVs geben, die ausgewählt werden können
- Die Ladeleistung muss mit rein
- Der gesamt Preis für's Laden sollte mit rein
- Es sollen direkt Monats/Jahres Summen gebildet werden
- Über ein DbRep sollen bisherige Informationen angezeigt werden, die die Orientierung bei der Erfassung ermöglichen
- Ein Löschen wäre schön
- Bei den Leistungsreports zur Wallbox für Monat/Jahr möchte ich das in dem BEV in der Statistik mit aufsummiert bekommen

Noch offene Fragen
- Braucht man die Ladekartennummer?
- Macht es Sinn fremde private Ladestellen separat zu reporten?
- Müssen auch die Kostenlosen Ladesäulen aufgelistet werden,
  oder erfasst man die mit einem eigenen Preis?

Leider bekomme ich von meiner Ladekarte über das Portal nur manuell einen EXCEL Report, eine API gibt es wohl nicht.
Einen Import in die Datenbank würde ich bevorzugen.

VG   Christian

[zwölfgang]

################################################################################################################
## 6 Wiederhole alle 180s die Kommandos der ExternControl Steuerung
##
16_Stop_Standby_Entladung

Hallo Christian,
ich hatt kürzlich den Block ins WR_1_Speicher_1_ExternControl eingebaut und dann wieder entfernt. Dazu habe ich es aus dem Wiki neu herauskopiert und installiert.
Jetzt passiert folgendes: Block 6,7,8 funktionieren nicht mehr. Im Log steht:

2023.01.09 23:18:02 4: WR_1_Speicher_1_ExternControl: condition c10: Unrecognized character \xC2; marked by <-- HERE after t   = (1 -<-- HERE near column 823, line 48.
in perl block: 6_Kommando_Wiederholung
2023.01.09 23:18:02 4: WR_1_Speicher_1_ExternControl: condition c11: Unrecognized character \xC2; marked by <-- HERE after SOCNew   =<-- HERE near column 292, line 42.
in perl block: 7_SOC_Calculation
2023.01.09 23:18:02 4: WR_1_Speicher_1_ExternControl: condition c12: Unrecognized character \xC2; marked by <-- HERE after  DOIF; if(<-- HERE near column 18, line 1.
in perl block: 8_Reset

Hab dann die drei Blöcke aus meiner Sicherung wieder eingebaut und alles funktioniert wieder, alle Blöcke stehen wieder auf executed
Kann es sein das ins Wiki ein Formatfehler wie es von Otto123 hier https://forum.fhem.de/index.php?topic=121864.0 beschrieben wurde da mit reingeschlüpft ist?

VG
Wolfgang

[zwölfgang]

Frage mal in die Runde,
wie kann man so einen Fehler in einem DOIF Reading bzw. Logeintrag finden?

2023.01.09 23:18:02 4: WR_1_Speicher_1_ExternControl: condition c10: Unrecognized character \xC2; marked by <-- HERE after t   = (1 -<-- HERE near column 823, line 48.
 in perl block: 6_Kommando_Wiederholung

Den Block habe ich gefunden aber column und line hat mir da nicht wirklich weiter geholfen.
Hat dazu jemand einen Hinweis?

VG Wolfgang

[ch.eick]

Hallo Christian,
ich hatt kürzlich den Block ins WR_1_Speicher_1_ExternControl eingebaut und dann wieder entfernt. Dazu habe ich es aus dem Wiki neu herauskopiert und installiert.
Jetzt passiert folgendes: Block 6,7,8 funktionieren nicht mehr. Im Log steht:
Hab dann die drei Blöcke aus meiner Sicherung wieder eingebaut und alles funktioniert wieder, alle Blöcke stehen wieder auf executed
Kann es sein das ins Wiki ein Formatfehler wie es von Otto123 hier https://forum.fhem.de/index.php?topic=121864.0 beschrieben wurde da mit reingeschlüpft ist?

Hallo Wolfgang,
copy/past könnte immer ein Problem sein

Ich habe es im Wiki nochmal aktualisiert und es mir dann auch im Notepad++ angeschaut.
Dort habe ich die Sonderzeichen aktiviert und nach "t   = (1" sucht kommt man an die Stelle wie im Bild.
Eventuell hilft das ja bei der Suche.

[ch.eick]

Frage mal in die Runde,
wie kann man so einen Fehler in einem DOIF Reading bzw. Logeintrag finden? Den Block habe ich gefunden aber column und line hat mir da nicht wirklich weiter geholfen.
Hat dazu jemand einen Hinweis?

Das ist immer schwierig, weshalb ich immer nur in kleinen Stücken Änderungen mache und teste.
Die line und column bezieht sich wohl auf den Block, der aktuell ausgeführt wurde, aber der fehler kann schon vorher im Code sein und sich erst dort auswirken.
Beim Suchen kann man dann zusätzliche Meldungen einfügen und so die Position im Code weiter einschränken.

Zusätzlich siehe auch den vorherigen Post.

[zwölfgang]

Hallo Christian,
hab das nochmal neu aus dem Wiki kopiert und mit defmod installiert, alle drei Fehler waren wieder da. Irgend etwas mach ich da wohl falsch.
Habe dann im Fhem Editor genau diese fehlerbehafteten Zeichenfolgen gesucht und neu geschrieben und siehe da, Fehler ist weg.
Sollte ich den Text aus dem Wiki zuerst noch in einen anderen Editor bearbeiten und dann ins FHEM einfügen ?
Irgendwie seltsam aber jetzt ist wieder alles gut.

VG Wolfgang

[MichaelO]

Moin zusammen,
nachdem ich mich momentan mit den hier aufgezeigten Berechnungen befasse und schon Einiges direkt mit Christian abgeklärt habe, würde ich gerne meine Einwände gegen die aktuelle Vorgehensweise zur Diskussion stellen.

Ausgangspunkt der Prognose ist RAD1h vom DWD. Gemäß deren Beschreibung gilt: "Die Globalstrahlung ist die gesamte am Erdboden ankommende solare Strahlung. Sie setzt sich aus der Direkt- und der Diffusstrahlung zusammen. Standardmäßig wird die Globalstrahlung und die Diffusstrahlung auf die horizontale Ebene bezogen gemessen. Aus beiden Komponenten lässt sich dann die Direktstrahlung ableiten."

In der Sub Solar_plain wird dann ausgerechnet, wie groß der Strahlungsanteil ist, der aufgrund der Ausrichtung der Module und des Sonnenstands noch zur Energiegewinnung beisteuert. Dieser Wert wird dann im weiteren Verlauf der Prognose mit Wetterphänomenen wie Regen/Wolken etc. "verrechnet".

Hier ist meiner Meinung nach jedoch schon der Ansatz in der Solar_plain falsch. Der Wert Rad1h sollte doch schon den Sonnenstand und Wetter berücksichtigen.

Momentan werden Strings, die zB gemäß Ausrichtung garnicht mehr beschienen sind, mit einem Prognosebetrag von 0Wh berechnet (Strings Richtung NordOst sobald die ganz im Schatten liegen). Diese liefern aber sehr wohl noch reichlich Energie, so dass hier systematisch die Prognose zu schlecht ausfällt. Man müsste doch eigentlich aus der Globalstrahlung die Direkt- und Diffusstrahlung berechnen, und das auf die Strings anwenden.

Die Direktstrahlung müsste theoretisch zusammen mit der Modulneigung betrachtet werden, um den Stundenertrag zu bekommen, also etwa so:

Code Auswählen Erweitern

cosinus = cos(string_plain);
string_power_estimation  = string_kWp * cosinus * Solar_SolarRadiation;

Während die Diffusstrahlung meiner Meinung nach zu 100% zum Ertrag beiträgt.

Zuletzt bin ich unsicher, ob die Globalstrahlung des DWD, die ja stationsbezogen bereitgestellt wird, nicht auch schon Faktoren wie Wolken und Regen berücksichtigt. Dann würde ja gleich mehrfach korrigiert. Auch wenn Wikipedia keine anerkannte wissenschaftliche Quelle darstellt, möchte ich zitieren: "Die Momentanwerte der Globalstrahlung unterliegen wetterbedingt starken Schwankungen durch Bewölkung und atmosphärische Trübung. Wegen des veränderlichen Einfallswinkels des Direktstrahlungsanteils ist die Globalstrahlung mittags stärker als morgens und abends, und im Sommer stärker als im Winter." Demnach ist die aktuell durchgeführte Korrektur zwar individuell anhand empirischer Daten und Schätzungen vielleicht ok, aber eigentlich enthält der bereitgestellte Wert bereits genau jene Faktoren.

[ch.eick]

Moin zusammen,
nachdem ich mich momentan mit den hier aufgezeigten Berechnungen befasse und schon Einiges direkt mit Christian abgeklärt habe, würde ich gerne meine Einwände gegen die aktuelle Vorgehensweise zur Diskussion stellen.

Ausgangspunkt der Prognose ist RAD1h vom DWD. Gemäß deren Beschreibung gilt: "Die Globalstrahlung ist die gesamte am Erdboden ankommende solare Strahlung. Sie setzt sich aus der Direkt- und der Diffusstrahlung zusammen. Standardmäßig wird die Globalstrahlung und die Diffusstrahlung auf die horizontale Ebene bezogen gemessen. Aus beiden Komponenten lässt sich dann die Direktstrahlung ableiten."

In der Sub Solar_plain wird dann ausgerechnet, wie groß der Strahlungsanteil ist, der aufgrund der Ausrichtung der Module und des Sonnenstands noch zur Energiegewinnung beisteuert. Dieser Wert wird dann im weiteren Verlauf der Prognose mit Wetterphänomenen wie Regen/Wolken etc. "verrechnet".

Hier ist meiner Meinung nach jedoch schon der Ansatz in der Solar_plain falsch. Der Wert Rad1h sollte doch schon den Sonnenstand und Wetter berücksichtigen.

Nur leider lag die Prognose ohne das noch viel weiter daneben
Ich fahre da einen empirischen Ansatz und das Ergebnis war mein Ziel. Das hat alles nichts mit echter Wissenschaft zu tun!

Momentan werden Strings, die zB gemäß Ausrichtung garnicht mehr beschienen sind, mit einem Prognosebetrag von 0Wh berechnet (Strings Richtung NordOst sobald die ganz im Schatten liegen). Diese liefern aber sehr wohl noch reichlich Energie, so dass hier systematisch die Prognose zu schlecht ausfällt. Man müsste doch eigentlich aus der Globalstrahlung die Direkt- und Diffusstrahlung berechnen, und das auf die Strings anwenden.

In der Solar_plain() werden Grenzwerte bewust auf 0.001 gesetzt, was bei jeder Installation etwas anders ausfallen könnte. Da ist dann noch Platz für Optimierung der eigenen Prognose.

Die Direktstrahlung müsste theoretisch zusammen mit der Modulneigung betrachtet werden, um den Stundenertrag zu bekommen, also etwa so:

Code Auswählen Erweitern

cosinus = cos(string_plain);
string_power_estimation  = string_kWp * cosinus * Solar_SolarRadiation;

Während die Diffusstrahlung meiner Meinung nach zu 100% zum Ertrag beiträgt.

Dem stimme ich zu.

Zuletzt bin ich unsicher, ob die Globalstrahlung des DWD, die ja stationsbezogen bereitgestellt wird, nicht auch schon Faktoren wie Wolken und Regen berücksichtigt. Dann würde ja gleich mehrfach korrigiert. Auch wenn Wikipedia keine anerkannte wissenschaftliche Quelle darstellt, möchte ich zitieren: "Die Momentanwerte der Globalstrahlung unterliegen wetterbedingt starken Schwankungen durch Bewölkung und atmosphärische Trübung. Wegen des veränderlichen Einfallswinkels des Direktstrahlungsanteils ist die Globalstrahlung mittags stärker als morgens und abends, und im Sommer stärker als im Winter." Demnach ist die aktuell durchgeführte Korrektur zwar individuell anhand empirischer Daten und Schätzungen vielleicht ok, aber eigentlich enthält der bereitgestellte Wert bereits genau jene Faktoren.

Das ist vollkommen richtig, wie Du das siehst. Nur sind halt leider die Ergebnisse der Prognose recht schlecht gewesen. Aus diesem Grund habe ich empirisch nach Verbesserungen gesucht und durch die Beobachtung der Außenwelt maßgeblich Wolken und Regen identifiziert Deshalb ist das dann mit eingeflossen und hat maßgeblich zu genaueren Ergebnissen geführt.

Das ist aber alles nicht in Stein gemeißelt und kann gerne verbessert werden. Ich bin da für alles offen und übernehme es gerne.

Mit @Peter arbeite ich wie gesagt an einer KI Variante, die sehr vielversprechend aussieht. Da gehen die DWD Werte und der tatsächliche Ertrag der gesamt Anlage rein, ohne das irgend etwas über die Anlage konfiguriert worden ist. Da wäre man dann weg von Modulen, Ausrichtung, Neigung und all dem anderen Zeugs
Die bisherige Prognose arbeitet seit fast 3 Jahren zufriedenstellend und ein neuer Weg mit viel weniger Konfigurationsaufwand hat sich bereits geöffnet, da kommt dann doch meine Faulheit durch

EDIT: Sobald Du die Graphen der Prognose mit Deinem Ertrag hast, könntest Du die mal schicken, dann können wir noch optimieren.

VG  Christian

[kaiman]

Hallo Christian,

ich habe einen Anzeigefehler und weiß nicht ganz, wo ich ansetzen kann. In der Tabelle fehlen die Angaben des letzen Jahre. Der SQL Lauf für das letzte Jahr ist gelaufen. Dennoch werden die Werte nicht angezeigt. Ich weiß aber, dass letztes Jahr die Werte von 2021 angezeigt wurden.

Hast du blind ne Idee, wo ich was anpassen müsste, oder benötigst du noch Infos?

LG

[ch.eick]

Hallo Christian,

ich habe einen Anzeigefehler und weiß nicht ganz, wo ich ansetzen kann. In der Tabelle fehlen die Angaben des letzen Jahre. Der SQL Lauf für das letzte Jahr ist gelaufen. Dennoch werden die Werte nicht angezeigt. Ich weiß aber, dass letztes Jahr die Werte von 2021 angezeigt wurden.

Hast du blind ne Idee, wo ich was anpassen müsste, oder benötigst du noch Infos?

LG

Die Ausgabe vom LogDBRep_Statistic_previous_Year war ganz gut. Wie sehen da die readings aus?

EDIT: Im WR_1_API stateFormat wären diese Zeilen wichtig.

Code Auswählen Erweitern


my $YearBefore      = "LogDBRep_Statistic_previous_Year";
my $YearPrevious    = ReadingsTimestamp("$YearBefore","SW_Statistic_Yield_Year","null");
   $YearPrevious = ($YearPrevious ne "null") ? POSIX::strftime("%Y",localtime(time_str2num(ReadingsTimestamp("$YearBefore","SW_Statistic_Yield_Year","null")))) : "null";


[ch.eick]

Soo, jetzt kommt noch ein Preview für das WB_0 Device und dann bin ich mal offline für den Rest der Woche.

Bisher funktioniert:
- Einfügen von Datensätzen
- Anzeige der der Datensätze mit 7 Tage vor und nach dem Datum
- Ein Report mit 30 Einträgen vor dem Datum
- Das löschen des Reports, damit die Anzeige im FHEMWEB nicht so voll ist

In der Datenbank sieht es bisher dann so aus, wobei die Summen für Monat und Jahr noch manuell erzeugt wurden.

Code Auswählen Erweitern


mysql> select * from history where DEVICE='WB_0' order by TIMESTAMP;
+---------------------+--------+---------+-------+---------------------------------+--------+------+
| TIMESTAMP           | DEVICE | TYPE    | EVENT | READING                         | VALUE  | UNIT |
+---------------------+--------+---------+-------+---------------------------------+--------+------+
| 2021-12-11 14:00:00 | WB_0   | privat  | NULL  | Kia_eNiro_lp_1_kWhActualCharged | 60     | NULL |
| 2021-12-11 14:00:00 | WB_0   | manuell | NULL  | Kia_eNiro_lp_1_kWhCost          | 32.40  | NULL |
| 2021-12-12 19:45:00 | WB_0   | Karte_1 | NULL  | Kia_eNiro_lp_1_kWhActualCharged | 31.55  | NULL |
| 2021-12-12 19:45:00 | WB_0   | manuell | NULL  | Kia_eNiro_lp_1_kWhCost          | 20.55  | NULL |
| 2021-12-25 16:30:00 | WB_0   | Karte_1 | NULL  | Kia_eNiro_lp_1_kWhActualCharged | 39.91  | NULL |
| 2021-12-25 16:30:00 | WB_0   | manuell | NULL  | Kia_eNiro_lp_1_kWhCost          | 25.21  | NULL |
| 2021-12-26 17:00:00 | WB_0   | Karte_1 | NULL  | Kia_eNiro_lp_1_kWhActualCharged | 10.9   | NULL |
| 2021-12-26 17:00:00 | WB_0   | manuell | NULL  | Kia_eNiro_lp_1_kWhCost          | 7.32   | NULL |
| 2021-12-31 23:00:00 | WB_0   | manuell | NULL  | Kia_eNiro_lp_1_kWhCounter_Year  | 142.36 | NULL |
| 2021-12-31 23:00:00 | WB_0   | manuell | NULL  | Kia_eNiro_lp_1_kWhCounter_Month | 142.36 | NULL |
| 2022-07-12 12:15:00 | WB_0   | Karte_1 | NULL  | Kia_eNiro_lp_1_kWhActualCharged | 23.75  | NULL |
| 2022-07-12 12:15:00 | WB_0   | manuell | NULL  | Kia_eNiro_lp_1_kWhCost          | 13.90  | NULL |
| 2022-07-12 14:45:00 | WB_0   | Karte_1 | NULL  | Kia_eNiro_lp_1_kWhActualCharged | 24.92  | NULL |
| 2022-07-12 14:45:00 | WB_0   | manuell | NULL  | Kia_eNiro_lp_1_kWhCost          | 14.81  | NULL |
| 2022-07-31 23:00:00 | WB_0   | manuell | NULL  | Kia_eNiro_lp_1_kWhCounter_Month | 48.67  | NULL |
| 2022-08-27 16:45:00 | WB_0   | manuell | NULL  | Kia_eNiro_lp_1_kWhCost          | 20.11  | NULL |
| 2022-08-27 16:45:00 | WB_0   | Karte_1 | NULL  | Kia_eNiro_lp_1_kWhActualCharged | 42.96  | NULL |
| 2022-08-31 23:00:00 | WB_0   | manuell | NULL  | Kia_eNiro_lp_1_kWhCounter_Month | 42.96  | NULL |
| 2022-12-26 14:00:00 | WB_0   | Karte_1 | NULL  | Kia_eNiro_lp_1_kWhActualCharged | 45     | NULL |
| 2022-12-31 23:00:00 | WB_0   | manuell | NULL  | Kia_eNiro_lp_1_kWhCounter_Month | 45     | NULL |
| 2022-12-31 23:00:00 | WB_0   | manuell | NULL  | Kia_eNiro_lp_1_kWhCounter_Year  | 136.63 | NULL |
| 2023-01-10 19:00:00 | WB_0   | Karte_1 | NULL  | Kia_eNiro_lp_1_kWhActualCost    | 8.90   | NULL |
| 2023-01-10 19:00:00 | WB_0   | Karte_1 | NULL  | Kia_eNiro_lp_1_kWhActualCharged | 12     | NULL |
+---------------------+--------+---------+-------+---------------------------------+--------+------+


[kaiman]

Die Ausgabe vom LogDBRep_Statistic_previous_Year war ganz gut. Wie sehen da die readings aus?

EDIT: Im WR_1_API stateFormat wären diese Zeilen wichtig.

Code Auswählen Erweitern


my $YearBefore      = "LogDBRep_Statistic_previous_Year";
my $YearPrevious    = ReadingsTimestamp("$YearBefore","SW_Statistic_Yield_Year","null");
   $YearPrevious = ($YearPrevious ne "null") ? POSIX::strftime("%Y",localtime(time_str2num(ReadingsTimestamp("$YearBefore","SW_Statistic_Yield_Year","null")))) : "null";


Hier die Zeilen im StateFormat:

my $YearBefore      = "LogDBRep_Statistic_previous_Year";
my $YearPrevious    = POSIX::strftime("%Y",localtime(time_str2num(ReadingsTimestamp("$YearBefore","SW_Statistic_Yield_Year","null"))));

Im Bild die Daten aus der LogDBRep_Statistic_previous_Year

[MichaelO]

Aktuell wird in der Prognose u. a. eine Korrektur über den Temperaturkoeffizienten der verbauten Module vorgenommen. Hierzu hätte ich Anmerkungen bzw. Fragen, ebenso zur Globalstrahlung.

1) Warum wird zur Vorhersagetemperatur des DWD für die Stunden 10 hinzugezählt?

Code Auswählen Erweitern

$Solar_Temp           = ReadingsVal($wetter,"fc".$fc."_".($i+$timeshift)."_TTT"  ,0)+10;

2) Gemäß Wiki soll der Wert $Solar_Temp die geschätzte erwartete Temperatur an den Modulen sein. Um den Wert präziser ermitteln zu können, habe ich nun in einer Dissertation die Berechnung der Modultemperatur nach Govindasamy, et al., 2012 gefunden (die Quellen habe ich nicht kontrolliert da nicht verfügbar) und bei mir implementiert. Darüber wird dann die Leistung entsprechend korrigiert. Für diesen Ansatz wird zusätzlich das Reading FF (Windgeschwindigkeit) vom DWD benötigt, das Device ist entsprechend zu erweitern und mit den Wetterdaten der Stunde über

Code Auswählen Erweitern

$Solar_Windspeed      = ReadingsVal($wetter,"fc".$fc."_".($loop_hour+$timeshift)."_FF",0) ;
in der Prognoseberechnung abzufragen. Dann erfolgt die Berechnung der Temperatur wie folgt:

Code Auswählen Erweitern


$tempk  = ReadingsVal($logdevice."_config","forecast_tempk",0) * -0.01;   # Temperaturkoeffizient des Strings 
if ($tempk ne 0) {
         $tempk_base  = ReadingsVal($logdevice."_config","forecast_tempk_base" ,0) ;   #
         # Berechnung Modultemperatur nach Govindasamy, et al., 2012
         $module_temp = 0.943 * $Solar_Temp + 0.028 * $Solar_SolarRadiation - 1,528 * $Solar_Windspeed + 4,3 ;
         # Berechnung Leistungskorrektur [%] aufgrund Modultemperatur
         $Solar_Correction_Temp = round( (($module_temp - $tempk_base) * $tempk),3) ;
}
Dann habe ich den Korrekturfaktor wie folgt angewendet ($Solar_Correction_Temp ist dann aus der Zeile mit Regen und Wolken zu entfernen):

Code Auswählen Erweitern


# Berechnung der Modul Nennleistung für diese Ausrichtung
$Solar_[$j]  = $module_count[$j] * ReadingsVal($logdevice."_config","module_".$j."_power",1)/1000 ;
# Anwendung der Korrekturfaktoren
$Solar_[$j] = $Solar_[$j] + ($Solar_[$j] * $Solar_Correction_Temp / 100) ;   # Korrektur der Modulleistung aufgrund Temperatur
$Solar_[$j]  = $Solar_[$j] * $Solar_Plain ;
...
Das wäre vielleicht ein weiterer Schritt Richtung besserer Prognose, den ich gerne zur Diskussion stelle.

3) Persönlich halte ich den Ansatz, ausschließlich über die Globalstrahlung per empirischer Beobachtungen den Anlagenfaktor für die Prognosen zu bestimmen, für unzweckmäßig. Wie man aus direkter, diffuser und reflektierter Strahlung eine gute Annäherung an die Realität hinbekommt, ist u. a. von Prof. Quaschning in einem seiner Bücher beschrieben. Da habe ich aber nur ein paar "hingeworfene" Formeln bislang im Netz gefunden, das Buch besitze ich nicht. Wenn hier jemand weiß, wie man aus dem Rad1h-Wert des DWD für den jeweiligen Ort auf die darin enthaltenen Anteile der Direkt- und Diffusstrahlung kommt (oder dafür eine andere Quelle mit öffentlicher Schnittstelle für die Stundenwerte kennt), dann wäre das aus meiner Sicht schon ein großer Schritt und ich wäre für eine Antwort dankbar. Die bisherige Anwendung von Wetter-Korrekturfaktoren, die bereits in den Basiswert eingepreist sind, halte ich wie schon gesagt für nicht zweckmäßig.

4) Die Prognose läuft derzeit von 6 bis 21 Uhr. Ich schlage vor, hier eine Startzeit von 5 Uhr und Endzeit 22 Uhr zu setzen, da im Sommer Ertrag auch in den bislang fehlenden Stunden vom Dach kommt und das die Prognose weiter verzerren würde.

@Christian: Hast Du meine überarbeitete sub Solar_forecast und das _config-Device schon anschauen können? Neben den Umbenennungen der Readings in selbsterklärendere Namen habe ich ja u. a. unnötige Arrays entfernt, das Log präzisiert und lesbarer gemacht sowie die Berechnungen etwas beschleunigt. Bei mir läuft es, soweit ich das beurteilen kann.

[ch.eick]

Aktuell wird in der Prognose u. a. eine Korrektur über den Temperaturkoeffizienten der verbauten Module vorgenommen. Hierzu hätte ich Anmerkungen bzw. Fragen, ebenso zur Globalstrahlung.

1) Warum wird zur Vorhersagetemperatur des DWD für die Stunden 10 hinzugezählt?

Code Auswählen Erweitern

$Solar_Temp           = ReadingsVal($wetter,"fc".$fc."_".($i+$timeshift)."_TTT"  ,0)+10;

Es wird eigentlich die Temperatur der Module benötigt Da niemand einen Sensor unter den Modulen hat habe ich die Prognose Temperatur genommen und etwas drauf geschlagen, da die Module bei Sonnenschein wärmer sind als die Umgebungstemperatur.

2) Gemäß Wiki soll der Wert $Solar_Temp die geschätzte erwartete Temperatur an den Modulen sein. Um den Wert präziser ermitteln zu können, habe ich nun in einer Dissertation die Berechnung der Modultemperatur nach Govindasamy, et al., 2012 gefunden (die Quellen habe ich nicht kontrolliert da nicht verfügbar) und bei mir implementiert. Darüber wird dann die Leistung entsprechend korrigiert. Für diesen Ansatz wird zusätzlich das Reading FF (Windgeschwindigkeit) vom DWD benötigt, das Device ist entsprechend zu erweitern und mit den Wetterdaten der Stunde über

Code Auswählen Erweitern

$Solar_Windspeed      = ReadingsVal($wetter,"fc".$fc."_".($loop_hour+$timeshift)."_FF",0) ;
in der Prognoseberechnung abzufragen. Dann erfolgt die Berechnung der Temperatur wie folgt:

Code Auswählen Erweitern


$tempk  = ReadingsVal($logdevice."_config","forecast_tempk",0) * -0.01;   # Temperaturkoeffizient des Strings 
if ($tempk ne 0) {
         $tempk_base  = ReadingsVal($logdevice."_config","forecast_tempk_base" ,0) ;   #
         # Berechnung Modultemperatur nach Govindasamy, et al., 2012
         $module_temp = 0.943 * $Solar_Temp + 0.028 * $Solar_SolarRadiation - 1,528 * $Solar_Windspeed + 4,3 ;
         # Berechnung Leistungskorrektur [%] aufgrund Modultemperatur
         $Solar_Correction_Temp = round( (($module_temp - $tempk_base) * $tempk),3) ;
}

Du schießt mit Kanone auf Spatzen
Für mich ist das wegen der KI schon fast EOL (end off live)

Dann habe ich den Korrekturfaktor wie folgt angewendet ($Solar_Correction_Temp ist dann aus der Zeile mit Regen und Wolken zu entfernen):

Code Auswählen Erweitern


# Berechnung der Modul Nennleistung für diese Ausrichtung
$Solar_[$j]  = $module_count[$j] * ReadingsVal($logdevice."_config","module_".$j."_power",1)/1000 ;
# Anwendung der Korrekturfaktoren
$Solar_[$j] = $Solar_[$j] + ($Solar_[$j] * $Solar_Correction_Temp / 100) ;   # Korrektur der Modulleistung aufgrund Temperatur
$Solar_[$j]  = $Solar_[$j] * $Solar_Plain ;
...
Das wäre vielleicht ein weiterer Schritt Richtung besserer Prognose, den ich gerne zur Diskussion stelle.

Du kannst ja gerne die Ergebnisse vergleichen und hier veröffentlichen.

3) Persönlich halte ich den Ansatz, ausschließlich über die Globalstrahlung per empirischer Beobachtungen den Anlagenfaktor für die Prognosen zu bestimmen, für unzweckmäßig. Wie man aus direkter, diffuser und reflektierter Strahlung eine gute Annäherung an die Realität hinbekommt, ist u. a. von Prof. Quaschning in einem seiner Bücher beschrieben. Da habe ich aber nur ein paar "hingeworfene" Formeln bislang im Netz gefunden, das Buch besitze ich nicht. Wenn hier jemand weiß, wie man aus dem Rad1h-Wert des DWD für den jeweiligen Ort auf die darin enthaltenen Anteile der Direkt- und Diffusstrahlung kommt (oder dafür eine andere Quelle mit öffentlicher Schnittstelle für die Stundenwerte kennt), dann wäre das aus meiner Sicht schon ein großer Schritt und ich wäre für eine Antwort dankbar. Die bisherige Anwendung von Wetter-Korrekturfaktoren, die bereits in den Basiswert eingepreist sind, halte ich wie schon gesagt für nicht zweckmäßig.

Genau das ist das Problem, ich lege Wert auf kostenlose verlässliche Daten, es sind schon viele Dienste im Netz erschienen, dann wieder verschwunden oder wurden kostenpflichtig.
Mit den wissenschaftlichen Formeln kann ich leider nichts anfangen. Ich freue mich aber auf Deine überarbeitete Version.

4) Die Prognose läuft derzeit von 6 bis 21 Uhr. Ich schlage vor, hier eine Startzeit von 5 Uhr und Endzeit 22 Uhr zu setzen, da im Sommer Ertrag auch in den bislang fehlenden Stunden vom Dach kommt und das die Prognose weiter verzerren würde.

Die Erfahrung hat gezeigt, dass vor 6 Uhr nicht wirklich viel zu erwarten ist, bei meiner Ost Seite kommt im Sommer noch nicht genug um das Haus zu versorgen, somit ist auch nichts zu verteilen.
Da spare ich dann einfach Daten.

@Christian: Hast Du meine überarbeitete sub Solar_forecast und das _config-Device schon anschauen können? Neben den Umbenennungen der Readings in selbsterklärendere Namen habe ich ja u. a. unnötige Arrays entfernt, das Log präzisiert und lesbarer gemacht sowie die Berechnungen etwas beschleunigt. Bei mir läuft es, soweit ich das beurteilen kann.

leider noch nicht, da ich momentan dienstlich unterwegs bin