76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[300P]

@Flachzange

Dadurch das die Sonne bei mir am Nachmittag von Nachbarn ab frühem Winter (Mitte / Ende Oktober) schon immer und dauerhaft Schatten wirft hat sich das bei mir bislang wohl so einigermaßen in der Vorhersage eingependelt.

ABER: Bei mir ist es auch manchmal nicht besser - aber eben andersherum:

PV Abweichung gestern: -52,1 % (mehr Ertrag) 

Da war für den ganzen Tag dichter Nebel vorhergesagt und schwupp's auf einmal und unvorbereitet ->>> weg war er ab 10:30 Uhr   

[Parallix]

...
Da war für den ganzen Tag dichter Nebel vorhergesagt und schwupp's auf einmal und unvorbereitet ->>> weg war er ab 10:30 Uhr   

Ähnliches gibt es hin und wieder auch bei mir. In aller Regel führt dies aber "nur" zu einer schlechten Prognose für den nächsten bzw. übernächsten Tag. Die Tagesprognose wird - zumindest bei mir - recht gut bei einer sich ggf. ändernden Situation angepasst.

[DS_Starter]

Moin,

zum Thema Verschattungsmodelle ...
wie Prallix schon ausgeführt hat, enthält SF bereits ein eingebautes Korrektursystem über Faktoren. In dieses System gehen Verschattungen ein, aber natürlich auch andere Faktoren wie Deltas von Wetter/Strahlung bzgl. Prognose/Ist.
Diese Korrekturen können sowohl positiven als auch negativen Einfluß haben. Durch den implementierten Medianansatz soll sich der "Kern" durchsetzen und Ausreißer (+-) eliminieren bzw. nicht betrachten werden.
Das Problem dabei: Wetterfehler und Verschattung vermischen sich und der Lernprozess ist langwierig.

Im Prinzip wäre ein Verschattungsmanagement in SF sogar ohne KI relativ gut mathematisch modellierbar. Im Grunde machen viele professionelle PV-Simulationsprogramme (PVGIS, PV*SOL, etc.) genau das: Astronomie + Geometrie + Verlustmodelle.
Für SF halte ich es für unrealistisch, ein vollständiges Raytracing oder 3D-Gebäudemodell nachzubauen, sondern ein pragmatisches Modell, das mit vertretbarem Konfigurationsaufwand einen Mehrwert bringt.

Im Prinzip wäre das vorhandene Autokorrekturprinzip mit einer Verschattungskomponente zu ergänzen, die aber nur bei klaren Wetter, z.B. Cloud < 20%, zum Tragen kommt. Für eine Verschattung ist nur der Direktstrahlungsanteil relevant.
Aktuell gibt es nur die statische Ergänzung via Setter pvCorrectionFactor_XX der das Benutzerwissen modelliert. Es ist also noch etwas Gehirnschmalz nötig, vor allem auch um das System administrativ durch der Anwender auch klar strukturiert und gut administrierbar zu halten.

Intern sieht die dynamische Matrix (Altitude.Cloudiness) für das Korrekturmanagement pro Stunde des Tages so aus:

Code Auswählen Erweitern

      pvcorrf: 0.35=1.02 5.0=1.14 5.100=0.54 5.10=0.97 5.15=1.00 5.20=0.96 5.25=0.86 5.30=0.98 5.35=1.51 5.40=0.90
               5.45=0.81 5.5=1.05 5.50=1.60 5.55=1.26 5.60=1.48 5.65=1.09 5.70=1.66 5.75=0.67 5.80=1.29 5.85=0.86
               5.90=1.29 5.95=0.90 10.0=1.14 10.00=0.84 10.05=1.75 10.100=0.90 10.10=0.97 10.15=1.33 10.20=0.96 10.25=1.24
               10.30=0.72 10.35=0.79 10.40=0.83 10.45=0.79 10.50=0.77 10.5=1.05 10.55=0.87 10.60=0.93 10.65=0.80 10.70=2.29
               10.75=0.60 10.80=1.08 10.85=1.24 10.90=0.95 10.95=0.64 15.00=1.01 15.0=1.14 15.10=0.97 15.100=0.63 15.15=1.00
               15.20=1.10 15.25=1.04 15.30=1.05 15.35=0.90 15.40=0.98 15.45=0.96 15.5=1.05 15.50=0.35 15.55=0.86 15.60=1.06
               15.65=0.96 15.70=0.68 15.75=0.79 15.80=0.63 15.85=0.60 15.90=1.14 15.95=1.01 20.00=0.99 20.0=1.14 20.10=0.97
               20.100=0.70 20.15=1.02 20.20=0.99 20.25=1.01 20.30=1.02 20.35=1.51 20.40=1.04 20.45=0.84 20.5=1.05 20.50=0.71
               20.55=0.95 20.60=0.84 20.65=1.22 20.70=1.12 20.75=0.82 20.80=0.74 20.85=1.14 20.90=0.77 20.95=0.84 25.0=1.14
               25.00=1.05 25.100=0.75 25.10=0.97 25.15=1.19 25.20=1.03 25.25=1.03 25.30=0.44 25.35=0.81 25.40=0.99 25.45=1.06
               25.50=1.07 25.5=1.05 25.55=0.95 25.60=1.20 25.65=0.66 25.70=1.01 25.75=1.01 25.80=0.76 25.85=0.99 25.90=0.93
               25.95=1.71 30.00=1.01 30.0=1.14 30.05=1.18 30.100=1.05 30.10=1.07 30.15=1.08 30.20=1.15 30.25=1.16 30.30=1.05
               30.35=1.51 30.40=0.98 30.45=1.29 30.5=1.05 30.50=0.82 30.55=1.10 30.60=0.89 30.65=0.97 30.70=1.02 30.75=1.02
               30.80=1.28 30.85=1.09 30.90=1.30 30.95=1.12 35.0=1.14 35.00=1.01 35.05=1.04 35.10=1.03 35.100=1.01 35.15=1.04
               35.20=1.02 35.25=1.04 35.30=0.98 35.35=1.01 35.40=1.02 35.45=0.74 35.50=0.99 35.5=1.05 35.55=1.08 35.60=0.99
               35.65=0.98 35.70=0.90 35.75=1.14 35.80=0.83 35.85=1.02 35.90=1.03 35.95=0.80 40.00=1.04 40.0=1.14 40.05=1.04
               40.10=1.09 40.100=1.11 40.15=1.00 40.20=0.96 40.25=1.06 40.30=1.04 40.35=1.03 40.40=0.99 40.45=1.03 40.5=1.05
               40.50=1.09 40.55=1.02 40.60=1.02 40.65=1.11 40.70=1.18 40.75=1.08 40.80=1.05 40.85=0.86 40.90=1.08 40.95=0.88
               45.0=1.14 45.100=0.54 45.10=0.97 45.15=1.00 45.20=0.96 45.25=0.86 45.30=0.98 45.35=1.51 45.40=0.90 45.45=0.81
               45.50=1.60 45.5=1.05 45.55=1.26 45.60=1.48 45.65=1.09 45.70=1.66 45.75=0.67 45.80=1.29 45.85=0.86 45.90=1.29
               45.95=0.90

Es erscheint mir zur Zeit sinnvoll, die Setter pvCorrectionFactor_XX so umzubauen, dass sie nur/überwiegend bei Direktstrahlung wirken und bei schlechten/diffusen Verhältnissen die Steuerung komplett der Autokorrektur zu überlassen, da Verschattung in diesen Situationen in den Hintergrund tritt.

Darüber ist noch zu sinnieren ...

LG,
Heiko

[Flachzange]

Es erscheint mir zur Zeit sinnvoll, die Setter pvCorrectionFactor_XX so umzubauen, dass sie nur/überwiegend bei Direktstrahlung wirken und bei schlechten/diffusen Verhältnissen die Steuerung komplett der Autokorrektur zu überlassen, da Verschattung in diesen Situationen in den Hintergrund tritt.

Ja und bei mir käme noch Azimut und Höhe der Sonne hinzu. Zwischen Mai und August funktioniert das aktuelle Modell bei mir schon gut.

[DS_Starter]

Das Azimut wird durch die Stunde des Tages abgebildet. Es ist durch die Winter/Sommerzeit fehlerbehaftet was ohnehin der Fall ist denn das Azimut ändert sich im Laufe einer Stunde. SF rechnet aber nur im Stundenschnitt sodass wir den Mittelwert als Bin verwenden.

Die Altitude der Sonne zu einer bestimmten Stunde des Tages wäre tatsächlich bei einer manuellen Eingabe noch wichtig. In der Autokorrektur ist sie enthalten.
Es würde zu einer relativ umfangreichen Matrix führen, die der User pro relevanter Stunde abhängig von der Altitude ausfüllen müsste. Wobei für die Altitude auch einige wenige Bins ausreichen dürften.

Allzu schwierig sollte eine solche Matrix auch nicht administrierbar sein?
Dadurch würde die Setter pvCorrectionFactor_XX abgelöst werden durch ein Attribut oder Schlüssel ShadeCorrection in Form eines JSON z.B.:

Code Auswählen Erweitern

  "hod_Altitude":<Faktor>
{
 "10_10":0.65,
 "11_15":0.72,
 "11_20":0.78,
 "12_20":0.91,
  ....
}

Diese Matrix würde dann nur bei Cloudiness < 20% angewendet werden. Ergänzt werde könnte noch ein Parameter der festlegt ob die Autokorrektur/KI die Festlegung überschreiben darf.