76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[TheTrumpeter]

Ich habe eine Frage bzw. eine Anregung zu den Daten von der SolCast-API:
Auf der Website stellt SolCast die erwartete Leistung für die konfigurierte Anlage sowie zusätzlich die 90- und 10%-Perzentilen dar. Lt. API-Dokumentation können diese Daten auch abgefragt werden.

Wäre es nicht sinnvoll die Verbrauchsplanung an der WorstCase-Vorhersage zu orientieren?
Gerade in den helleren Monaten würde das meiner Meinung nach Sinn machen.

[DS_Starter]

Moin,

Auf der Website stellt SolCast die erwartete Leistung für die konfigurierte Anlage sowie zusätzlich die 90- und 10%-Perzentilen dar. Lt. API-Dokumentation können diese Daten auch abgefragt werden.

Wäre es nicht sinnvoll die Verbrauchsplanung an der WorstCase-Vorhersage zu orientieren?

Diese Möglichkeit ist schon gegeben. Mit dem Attribut affectSolCastPercentile kannst du die Auswahl des abgerufenen Perzentils bestimmen.

Grüße,
Heiko

[TheTrumpeter]

affectSolCastPercentile

Wie wirkt sich das dann auf die gelernten Korrekturfaktoren aus?
Ich hätte verstanden, dass auf Basis der Abweichung zwischen IST und Prognose der Korrekturfaktor "gelernt" wird (abhängig von Wetter und/oder Uhrzeit?)
Wenn ich nun auf eine pessimistischere Prognose umstelle, würde das durch die Lernfunktion über den Korrekturfaktor doch wieder kompensiert, oder verstehe ich da was falsch?

Meine Idee war eher, dass zwar die "globale/generelle" Vorhersage so läuft wie bisher, für die Verbrauchsplanung aber die WorstCase-Daten verwendet werden (zumindest solange sich alle Verbraucher auch mit den WorstCase-Daten unterbringen lassen).

[DS_Starter]

Wenn ich nun auf eine pessimistischere Prognose umstelle, würde das durch die Lernfunktion über den Korrekturfaktor doch wieder kompensiert, oder verstehe ich da was falsch?

Nein, das verstehst du völlig richtig. So ist es.
EDIT: Du kannst natürlich auch ohne Learning/Korrekturfaktorberechnung arbeiten -> "set ... pvCorrectionFactor_Auto noLearning".

Meine Idee war eher, dass zwar die "globale/generelle" Vorhersage so läuft wie bisher, für die Verbrauchsplanung aber die WorstCase-Daten verwendet werden (zumindest solange sich alle Verbraucher auch mit den WorstCase-Daten unterbringen lassen).

Das hatte ich fast befürchtet.
Das würde bedeuten, es müsste eine zweite "Schattenprognose" mit allen Mechanismen (wie Autokorrektur, Auswertung für Consumer Steuerung) parallel mitlaufen. Wahrscheinlich kannst du dir vorstellen wie aufwändig so etwas wäre und würde die aktuelle Komplexität noch einmal potenzieren. Noch dazu wäre dieses Feature nur auf SolCast beschränkt und mit wahrscheinlich wenig Effekt.
Da verwende ich meine Kraft und Zeit lieber in die Integration einer weiteren API wie der DWD ICON API.

Das sie für Zentraleuropa bereitgestellt wird, könnte sie auch für Österreich genau richtig sein. Auf der Webseite kannst du das mal checken.
Diese API ist vllt. eine echte Alternative zu SolCast (wegen der Beschränkungen).

[TheTrumpeter]

zweite "Schattenprognose" mit allen Mechanismen (wie Autokorrektur, Auswertung für Consumer Steuerung) parallel mitlaufen

Das ist die Frage...
2. Autokorrektur würde ich eher "nein" sagen, weil es ohnehin schon eine WorstCase-Prognose ist. Die muss man aus meiner Sicht weder nach unten noch nach oben korrigieren. SolCast berücksichtigt die Wetterprognose ja selbst in den Werten, warum also da auf Basis der Wetterprognose nochmal was korrigieren?
Die automatische Consumer-Steuerung müsste nur die "WorstCase-" statt der realistischen Prognose ansetzen.

Noch dazu wäre dieses Feature nur auf SolCast beschränkt und mit wahrscheinlich wenig Effekt.

Bzgl. SolCast gebe ich Dir Recht.
Über den Effekt lässt sich vmtl. streiten: Ich habe kürzlich die Warmwasser-Bereitung (über Wärmepumpe) von "must" auf "can" in Kombination mit spignorecond umgestellt. Die Bedingung in der spignorecond ist nun die, die ich davor in swoncond hatte ("Speichertemperatur verhältnismäßig niedrig"). Die Bedingung in swoncond habe ich so angepasst, dass ein Betrieb nicht nötig, aber bei ausreichend Überschuss sinnvoll wäre ("Speichertemperatur ausreichend hoch, aber Potenzial zum Nachheizen vorhanden"). Seit dieser Umstellung scheint der Verbraucher zum frühestmöglichen Zeitpunkt am Tag eingeplant zu werden, vor der Umstellung war es immer zum Zeitpunkt mit der prognostiziert höchsten PV-Leistung, selbst wenn davor schon mehr als genug Leistung vorhanden gewesen wäre.
Bisher ist das immer gut gegangen und es war schon früh genug ausreichend Leistung vorhanden, wenn die spignorecond zugetroffen hat, aber das liegt wohl eher an dem aktuell konstant sonnigem Wetter. Mit der "worst case" Einplanung würde auch bei weniger zutreffender Prognose tendenziell ein besseres Zeitfenster gewählt werden.

DWD ICON API.

Wenn Du das vor der Geosphere Austria angehst, würd' ich das jedenfalls mal ausprobieren, ja.

[DS_Starter]

Das ist die Frage...
2. Autokorrektur würde ich eher "nein" sagen, weil es ohnehin schon eine WorstCase-Prognose ist. Die muss man aus meiner Sicht weder nach unten noch nach oben korrigieren. SolCast berücksichtigt die Wetterprognose ja selbst in den Werten, warum also da auf Basis der Wetterprognose nochmal was korrigieren?

Auch ohne Autokorrektur bleibt es bei einer "Schattenprognose" die verwaltet werden muß.
Schon allein die theoretische Frage wann ein Nutzer/Consumer die normale oder die Schattenprognose nutzen soll lässt sich nicht anhand von auswertbaren Parametern beantworten.

Bzgl. SolCast gebe ich Dir Recht.
Über den Effekt lässt sich vmtl. streiten:...

Ich erweitere mein Statement:  ... -> mit wahrscheinlich wenig Effekt gemessen an dem Aufwand den ich an Zeit investieren müsste ...

Ich gebe natürlich zu, dass dein Anwendungsfall diesbezüglich sehr interessant ist.
Wir müssten mal überlegen, ob sich der gleiche Effekt nicht durch einen geschickten Einsatz der vorhandenen Consumerschlüssel (oder vllt. eines weiteren) erreichen ließe.

Alternativ wäre auch möglich, eine zweite SolarForecast Instanz zu erstellen, die du nur mit dem Perzentil 10 und den relevanten Consumern ohne Learning/Korrektur laufen lässt.

Verstehe mich bitte nicht falsch, aber allein schon die Consumer Verwaltung ist intern schon sehr komplex. Die Integration einer Parallelwelt mit nicht determinierbaren Auswahlkriterien führt zu einem nicht mehr beherrschbaren Konstrukt. Das Ganze muß ja auch noch pflegbar, supportbar und beschreibbar/erklärbar bleiben. Mal von meinem Zeitkontingent abgesehen.

[Bison]

Hallo zusammen,

ich spiele gerade mit dem Gedanken im Modul 76_SolarForecast eine Virtuellen Batterie zu implementieren. Das heißt über einen Dummy die Einspeisung als BatIn und den Netzbezug als BatOut zu bewerten. Diese Werte werden bis 0 oder BatCap aufsummiert/subtrahiert. Hat sich jemand ebenfalls Gedanken in diese Richtung gemacht?

Vielleicht gibt es ja Interesse an so einer Lösung.

Ich freue mich über eure Rückmeldung.


Gruß Bison

[TheTrumpeter]

Verstehe mich bitte nicht falsch, aber allein schon die Consumer Verwaltung ist intern schon sehr komplex. Die Integration einer Parallelwelt mit nicht determinierbaren Auswahlkriterien führt zu einem nicht mehr beherrschbaren Konstrukt. Das Ganze muß ja auch noch pflegbar, supportbar und beschreibbar/erklärbar bleiben. Mal von meinem Zeitkontingent abgesehen.

Überhaupt kein Thema, ich wollte es mal als Anregung in den Raum werfen, erwarte aber natürlich nicht, dass es vorbehalt- und/oder diskussionslos umgesetzt wird.
Ich kann mir gut vorstellen, dass in die Entwicklung einiges an Aufwand reinfließt und insgesamt ist die Komplexität sicher jetzt schon hoch.

Der Vorschlag mit der 2. Instanz ist gut, wg. der SolCast-Limitierung müsste ich einfach einen 2. Account dafür anlegen & wohl auch endlich mal die Reparatur meiner Peripherie am RasPi angehen, damit ich in dem Zuge gleich den 3B gegen einen 4er mit 4GB RAM tauschen kann.

[300P]

Hallo zusammen,

ich spiele gerade mit dem Gedanken im Modul 76_SolarForecast eine Virtuellen Batterie zu implementieren. Das heißt über einen Dummy die Einspeisung als BatIn und den Netzbezug als BatOut zu bewerten. Diese Werte werden bis 0 oder BatCap aufsummiert/subtrahiert. Hat sich jemand ebenfalls Gedanken in diese Richtung gemacht?

Vielleicht gibt es ja Interesse an so einer Lösung.

Ich freue mich über eure Rückmeldung.


Gruß Bison

Guten Morgen,

worin soll denn da der Sinn sein - gibt es dazu einen besonderen Grund ? 

[Reinschki]

  Und wenn sich jetzt das Wetter noch an die Vorhersage halten würde!

Du darfst diesen Dateianhang nicht ansehen.

Spass beiseite! Ich habe es richtig verstanden, dass das Modul jetzt selbstständig lernt und sich mit der Zeit anpasst?

VG
Reiner

[300P]

Ja, sollte so sein !

PS:
Upload Screenshot wieder nicht lesbar....
PPS:
Nach 45 Minuten  geht es jetzt

[DS_Starter]

Wenn es ein bisschen in die Schule gegangen ist, kann es dann so aussehen.... 
Es ist aber etwas Geduld gefragt! Die Korrekturwerte sind für jede einzelne Stunde abhängig von der prognostizierten Bewölkung, Strahlung und den realen Werten.
An der LED "Qualität" kann man das bisher erreichte Verhältnis zwischen Prognose und realem Ertrag der aktuellen Stunde nach einem Ampelsystem abschätzen.

[kask]

Ich habe mir eine Dummy gebastelt aus 3 Forecast's, SolcastAPI, DWD, Victron.
Damit bekomme ich eine homogenere genauer Vorhersage, wie ich finde.
Die ForecastSolarAPI habe ich auch noch aber die bekomme ich nicht brauchbar in den Griff. Für heute war er ausnahmesweise einiger massen brauchbar.



@DS_Starter

Da verwende ich meine Kraft und Zeit lieber in die Integration einer weiteren API wie der DWD ICON API.

Du bist ja immer flott mit sowas. Wann kann man damit rechnen bzw. hast du dir die Sache schon einmal genauer angeschaut? Schon eine grobe Einschätzung?
Nicht das ich es unbedingt sofort brauche. Aber "haben" ist besser als "brauchen"

[DS_Starter]

Ja, habe es mir bereits angeschaut.
Ich hoffe am WE eine erste brauchbare Implementierung testen zu können.

[Bison]

Hallo zusammen,

ich spiele gerade mit dem Gedanken im Modul 76_SolarForecast eine Virtuellen Batterie zu implementieren. Das heißt über einen Dummy die Einspeisung als BatIn und den Netzbezug als BatOut zu bewerten. Diese Werte werden bis 0 oder BatCap aufsummiert/subtrahiert. Hat sich jemand ebenfalls Gedanken in diese Richtung gemacht?

Vielleicht gibt es ja Interesse an so einer Lösung.

Ich freue mich über eure Rückmeldung.


Gruß Bison

Guten Morgen,

worin soll denn da der Sinn sein - gibt es dazu einen besonderen Grund ? 

Ich möchte mit verschiedenen Batteriegrößen spielen, um zu sehen welche Größe die optimale ist.