Ich habe ein wenig mit der API experimentiert und dem horizont Parameter entdeckt. Die PV Vorhersagen sind für meinen Standort leider viel zu hoch, da ich am Wald wohne und gerade im Winter deutlich weniger Ertrag habe. Also habe ich versucht das mit dem horizont zu kompensieren.
Aber egal was ich angebe, power und dcPower bleiben gleich. Der Parameter selber wird erkannt:
Zum Test hatte ich 25t0.3 angeben. Leider ändert sich die dcPower oder Power Werte im Ergebnis überhaupt nicht. Selbst ein „unsinnigen“ Werten von t0.01 nicht. Er bleibt immer bei den 22,18
So wie ich mich erinnere must du die Azimuth-Werte und die Horizont-Werte als kommagetrennte Liste an die Akkudoktor API schicken. Für die Azimutwerte gilt: north=+-180, east=-90, south=0, west=90. Die Horizontwerte gibst du passend zu den Azimutwerten dann einfach als Grad 0..90 an.
“For this, you use can a comma separated string with obsticals hight in angle (-180 = north, -90 = east, 0 = south, 90 = east). Also transparency is optional supported with a "t" after angle”
Also meint 25t0.3, dass eine eine Bereich (-180 - +180) Grad gibt und bis 25Grad Verschattung bei 30% transaprent. So lese ich auch die Antwort vom Service. Nur ändern sich die Werde nicht
Das ist die Definition von PVGIS, eigentlich der Standard bei solchen Daten:
”The horizon heights in the file should be given in a clockwise direction starting at North; that is, from North, going to East, South, West, and back to North. The values are assumed to represent equal angular distance around the horizon. For instance, if you have 36 values in the file, PVGIS assumes that the first point is due north, the next is 10 degrees east of north, and so on, until the last point, 10 degrees west of north.”
Es würde mich auch interessieren bei welcher Himmelsrichtung akkudoktor.net in der Liste für die Horizontwerte anfängt.
Guter Hinweiß. Aber erst mal möchte ich verstehen, was da falsch läuft. Ein Fehler bei meiner Nutzung oder ein Bug in der API? Wenn man nur einen Wert angibt, dann ist es erst mal egal, ob es von -180 - +180 geht oder anders rum.
Leider ist die Email von API-Team aus dem Swagger nicht mehr gültig. Vielleicht schau ich mit die API mal an. ggf. muss man ja einfach einen Account nutzen oder so was.
Ok, ich habe mir die API mal angesehen. An den Randbereichen von Sonnenaufgang sind die Werte von “direct_normal_irradiance” noch 0 und damit wirkt wohl nur die indirekte Einstrahlung auf die Zellen und die Verschattung hat keine Auswirkung. Im Laufe des Tages verringern sich die Wert schon im Vergleich.
Damit ist mein Punkt soweit klar. Aber Achtung, im Swagger ist ein Fehler in dem Bereich. Das Beispiel sagt 20t30, die Beschreibung 10t0.3,15t0.8. Die Werte zwischen 0…1 sind richtig. 20t30 müsste 20t0.3 heißen.
Auch habe ich noch einen Bug im DEBUG mode gefunden, der die API abstürzen lässt. Leider schient der Code aktuell nicht mehr bereut zu werden. Ein PR schient also nutzlos. Wobei der Fehler auch keinen Einfluss auf den normalen Betrieb hat.
Ich leite es mal an Nick weiter. Allerdings ist der forecast im EOS integriert und läuft da eigentlich ganz gut. Horizont funktioniert auch.
Ihr könnt dort im Code schauen, die Integration ist dort auf jeden Fall richtig.