SolXpect input

[woheller69]

Wollt ihr das am Ende in Java machen? Wenn "Ja" könntet ihr einfach meine SolarPowerPlant Klasse (und vieles andere) kopieren (unter GPL 3 Lizenz) https://github.com/woheller69/solxpect/blob/main/app/src/main/java/org/woheller69/weather/SolarPowerPlant.java Die Vewendung sieht man hier: https://github.com/woheller69/solxpect/blob/main/app/src/main/java/org/woheller69/weather/weather_api/open_meteo/OMDataExtractor.java

Verschattung kann bei mir in 10° Bereichen eingegeben werden. Oberhalb Winkel x freie Sicht, darunter y% Verschattung. https://github.com/woheller69/solxpect/blob/main/fastlane/metadata/android/en-US/images/phoneScreenshots/04.png

Zur Rechnung des Skalarprodukts über die Fläche: Ich weiß nicht, wie das funktionieren soll. Letzten Endes muß trotzdem ein Einstrahlungswinkel mit der Flächennormale multipliziert werden. Wenn da < 0 rauskommt nutzt das Integral der Fläche auch nichts. Wenn überhaupt, dann muss das Skalarprodukt für jede Minute oder ein anderes Intervall gerechnet und gemittelt werden.

[gvzdus]

Nein, Nick wird für die API das sicherlich in NodeJS oder Python implementieren - sind halt seine Sprachen, meine ist Java. Letztlich geht es ja um 100-200 Zeilen. "PVProject" soll nur den Algorithmus checken. Ich möchte aber so nah wie möglich an Deiner "SolarPowerPlant"-Klasse bleiben, damit man Unterschiede stets nachvollziehen kann.

Ich hatte wie bei Dir Verschattung in 10°-Schritten implementiert, aber m.E. mit einem anderen Mapping. Das sollte ich noch umstellen, damit wir kompatibel sind.

"Über die Fläche" war einfach nur meine "anschauliche" Vorstellung eines Algorithmus. Meine Grundidee aktuell: Innerhalb der Stunde in 1° Schritten (= 4 Minuten / 15 Schritte) durch-iterieren, dabei Elevation & Azimuth der Sonne linear interpolieren, ebenso das Vektorenprodukt Anfang / Ende. Dann kann ich für jede Azimut-Gradzahl den Horizont prüfen.

Anregung an SolEpect: Ich habe keine Ahnung, wie "teuer" ein Sin/Cos auf dem Handy ist. Aber die Werte der PV-Plane könnte man fix speichern, sie ändern sich ja nicht.

[woheller69]

Die Bewegung der Sonne ist nicht linear 1° pro 4 min. Das hängt von der Position ab.

Die Berechnung des default Wertes für diffuse Efficiency werde ich auch noch als statische Methode in die SolarPowerPlant Klasse verschieben. Dann ist alles zusammen. diffuseEfficiency = (int) ( 50 + 50 Math.cos(tilt/180Math.PI));

Ja, die cos Werte könnte man speichern, aber das macht es komplizierter. Performance auf dem Handy ist ja gut...

[gvzdus]

So, ich habe jetzt meinen mutmaßlich ersten Wurf der "jaja-in-etwa-1-Grad-Schritte"-Berechnung implementiert. Sind die Änderungen an Main.java. Die Kommentare sind hoffentlich sprechend. solar.properties ist nochmal etwas geändert: Ich habe mir den Winkel zu meinem Berg mal in Google Earth genauer angesehen. Hauptproblem für genaue "Sonnenaufgangsanbeter" scheinen aber die OpenMeteo-Daten selbst zu sein. Beispiel: Heute war bei mir um 05:19 Sonnenaufgang, um 06:00 Uhr produzierte die Anlage - zu 2/3 nach SO ausgerichtet - bereits 3% des Maximalwertes mit einer "Bilderbuch-Kurve" und natürlich massig Direkteinstrahlung.

URL für heute: https://api.open-meteo.com/v1/forecast?latitude=51.066168&longitude=6.590032&hourly=temperature_2m,direct_normal_irradiance,direct_normal_irradiance_instant&daily=sunset&forecast_days=1&timezone=Europe%2FBerlin

Während der Wert für direct_normal_irradiance_instant realistische 31,4 W anzeigt, ist der Summenwert direct_normal_irradiance 0. Das ist natürlich Quatsch.

[woheller69]

die 31.4W sind der Wert um 6:00

direct_normal_irradiance ist der Durchschnittswert der vorangegangenen Stunde also zwischen 5:00 und 6:00

Sollte deutlich kleiner als 31.4 sein, aber wohl nicht 0.0

Vielleicht mal ein issue aufmachen und fragen

[woheller69]

der Azimuthverlauf kann stark abweichen.

https://de.planetcalc.com/4270/

Probier mal verschiedene Breitengrade aus.

Wenn schon, dann für alle 4min Grena3 laufen lassen ...

[woheller69]

ich hab mal ein issue aufgemacht.

https://github.com/open-meteo/open-meteo/issues/367

[gvzdus]

der Azimuthverlauf kann stark abweichen.

Ja, das ist beim 25 Breitengrad schon heftig aktuell. Aber der Hintergrund ist ja, dass die Sonne fast senkrecht dort steht. Bedeutet: Fast nur für präzise senkrecht montierte Module ist der Azimut relevant, der Horizontwinkel ebenfalls irrelevant. Vielen Dank für das Issue-Öffnen!

[gvzdus]

Die Methode, die "direct_normal_radiation" zu verteilen, ist übrigens etwas "wild": Sonne innerhalb der Stunde über 0° Elev.: Gleichverteilt über die Stunde. Sonne am Anfang oder Ende < 0°: Gewichtet mit Elevation. Beides kommt mir aber nicht falsch vor, wenn ich mir eine typischen Ertragskurve ansehe. Aber im Grenzbereich, wenn der Sonnenaufgang nahe der Stundengrenze fällt, ist es natürlich ein klarer Unterschied im Algorithmus. Würde ich hier die Formel für die Dämpfung der Strahlung bei langem Athmosphärenweg einpflegen, wäre es aber wohl teuer in der Rechenzeit.

[woheller69]

ich würde eher alles mit Elevation >0 gleich gewichten. Also gleichverteilt über den Zeitraum, in dem die Sonne sichtbar ist

[gvzdus]

Ja, wenn durchgängig >= 0 in der Stunde, dann wichte ich das auch gleich. Wie wollen wir jetzt vorgehen mit der "DNI-Schwäche" der OpenMeteo-API? Mir ist jetzt nicht ganz klar, ob "sie" da etwas verbessern wollen. M.E. ist das Thema schon relevant, gerade z.B. für die senkrecht / fast senkrecht am Balkon hängenden Module. Man könnte:

• Nix machen oder auf eine Lösung bei OpenMeteo hoffen
• Sich selber mit Airmass-Berechnung etc. rumschlagen oder gucken, ob man mit der DWD-Api ergänzt.

[woheller69]

Eigentlich nur für senkrecht hängende Module, die auch noch Richtung Osten ausgerichtet sind. In meiner App werde ich nichts ändern.

Du kannst meinen letzten Vorschlag ausprobieren:

if (dni == 0) dni = direct_radiation/cos(85°)

[nick81nrw]

Bringt die 15-Minuten Betrachtung des DWD denn vielleicht bessere Werte?

[woheller69]

das macht es auf jeden Fall komplizierter. Die musst Du dann selbst beim DWD abrufen. Außerdem will Open-Meteo künftig auch 15min Werte in die allgemeine API übernehmen. Da kann man Patrick dann sicher auch dazu bringen, die Strahlungsdaten mit einzubauen. Ich würde die mal machen lassen. Open-Meteo ist ja noch im Aufbau.

[nick81nrw]

open-meteo liefert doch 15-min Werte von DWD. Zumindest radiation. Temperatur aber nur Stundenweise

https://api.open-meteo.com/v1/dwd-icon?latitude=52.52&longitude=13.41&hourly=temperature_2m&minutely_15=shortwave_radiation,diffuse_radiation,direct_normal_irradiance

[woheller69]

Ah, hatte ich nicht gesehen.

Wenn ihr nur eine Lösung für Deutschland wollt, könnt ihr natürlich direkt auf die DWD API gehen. Früher oder später kommt das aber auch in die weltweite API

[nick81nrw]

Ja, da hast du natürlich Recht mit der Begrenzung auf DE Wetterdaten. Die Frage die ich eher habe, bringt eine 15-minuten Betrachtung überhaupt Besserungen bei der Genauigkeit der Daten? Ich kann das leider nicht prüfen wegen fehlenden Ist-Daten. @gvzdus, kannst du das Prüfen?