INFO: Wie wird die Prognose-KI (ZARA) trainiert -> Wie funktioineren SFML und TFS

Hier auch gut zu sehen.
Das sind die einstrahlwerte vom Forecast heute morgen.

Using Open-Meteo GHI for 2026-04-28 hour 8: 126.0 W/m² (cloud_cover=50%)
Using Open-Meteo GHI for 2026-04-28 hour 9: 277.0 W/m² (cloud_cover=72%)
Using Open-Meteo GHI for 2026-04-28 hour 10: 442.0 W/m² (cloud_cover=70%)
Using Open-Meteo GHI for 2026-04-28 hour 11: 582.0 W/m² (cloud_cover=80%)
Using Open-Meteo GHI for 2026-04-28 hour 12: 680.0 W/m² (cloud_cover=81%)
Using Open-Meteo GHI for 2026-04-28 hour 13: 726.0 W/m² (cloud_cover=82%)
Using Open-Meteo GHI for 2026-04-28 hour 14: 710.0 W/m² (cloud_cover=83%)
Using Open-Meteo GHI for 2026-04-28 hour 15: 636.0 W/m² (cloud_cover=84%)
Using Open-Meteo GHI for 2026-04-28 hour 16: 526.0 W/m² (cloud_cover=85%)
Using Open-Meteo GHI for 2026-04-28 hour 17: 393.0 W/m² (cloud_cover=85%)
Using Open-Meteo GHI for 2026-04-28 hour 18: 256.0 W/m² (cloud_cover=86%)
Using Open-Meteo GHI for 2026-04-28 hour 19: 140.0 W/m² (cloud_cover=84%)

Hohes “cloud” cover, hohe einstrahlung

Hier die Vorhersage für morgen.

Using Open-Meteo GHI for 2026-04-29 hour 7: 21.0 W/m² (cloud_cover=20%)
Using Open-Meteo GHI for 2026-04-29 hour 8: 126.0 W/m² (cloud_cover=10%)
Using Open-Meteo GHI for 2026-04-29 hour 9: 290.0 W/m² (cloud_cover=8%)
Using Open-Meteo GHI for 2026-04-29 hour 10: 480.0 W/m² (cloud_cover=7%)
Using Open-Meteo GHI for 2026-04-29 hour 11: 643.0 W/m² (cloud_cover=4%)
Using Open-Meteo GHI for 2026-04-29 hour 12: 764.0 W/m² (cloud_cover=3%)
Using Open-Meteo GHI for 2026-04-29 hour 13: 839.0 W/m² (cloud_cover=2%)
Using Open-Meteo GHI for 2026-04-29 hour 14: 863.0 W/m² (cloud_cover=1%)
Using Open-Meteo GHI for 2026-04-29 hour 15: 829.0 W/m² (cloud_cover=1%)
Using Open-Meteo GHI for 2026-04-29 hour 16: 743.0 W/m² (cloud_cover=0%)
Using Open-Meteo GHI for 2026-04-29 hour 17: 617.0 W/m² (cloud_cover=0%)
Using Open-Meteo GHI for 2026-04-29 hour 18: 461.0 W/m² (cloud_cover=0%)
Using Open-Meteo GHI for 2026-04-29 hour 19: 289.0 W/m² (cloud_cover=0%)
Using Open-Meteo GHI for 2026-04-29 hour 20: 121.0 W/m² (cloud_cover=0%)
Using Open-Meteo GHI for 2026-04-29 hour 21: 11.0 W/m² (cloud_cover=0%)

Es ist schwer, da alles richtig zu machen, und es gibt sicher mehrere Wegen wie man die Prognose angehen kann.

@anon90989627,

vielen Dank für deine Ausführungen. Ich habe deine Beiträge aufmerksam gelesen, sehe jedoch einige grundlegende Missverständnisse bezüglich der technischen Funktionsweise und der zugrunde liegenden Modellierung. Neben der Sprachbarriere scheint hier ein Informationsdefizit bezüglich der logischen Abläufe vorzuliegen.

1. Komplexität der atmosphärischen Einflussfaktoren

Deine Annahme, Bewölkung ließe sich über einen pauschalen Korrekturfaktor (z. B. -20 %) auf Papier kalkulieren, ist wissenschaftlich nicht belastbar, sondern geradezu fahrlässig falsch. Die reale Globalstrahlung auf die Modulfläche wird von weitaus mehr Faktoren beeinflusst als von der rein visuellen Bewölkung in Wetter-Apps:

  • Aerosole und Partikel: Faktoren wie Pollenflug, Saharastaub oder Luftverschmutzung wirken als Strahlungshemmer, ohne dass diese vom Boden aus zwingend als Bewölkung wahrnehmbar sind.
  • Atmosphärische Beschaffenheit: Luftdichteänderungen und die Schichtung der Atmosphäre beeinflussen die Transmission maßgeblich.
  • Diffuse vs. Direkte Strahlung: Zwei Tage mit scheinbar identischem „blauem Himmel“ können aufgrund der Strahlungsdichte und Temperatur drastisch unterschiedliche Ertragswerte liefern.
  • Geometrische Faktoren: Standortspezifische Verschattungsprofile und der exakte Sonnenstand werden in der Integration hochpräzise berechnet.

2. Differenzierung: Statische Prognose vs. Rolling Horizon

Ein wesentlicher Punkt ist die Definition dessen, was eine Prognose eigentlich ist. Ich verfolge bewusst einen statischen Ansatz. Eine „rollende Prognose“ (Rolling Horizon) ist methodisch eher als kurzfristige Zustandskorrektur zu betrachten.

Wichtig zur Abgrenzung: Systeme von Fronius, VW, BMW, Anker etc. sind Energiemanager, keine Prognosen! Sie steuern Energieflüsse auf Intraday-Ebene, um das vorhandene Potenzial bestmöglich zu nutzen – NICHT das prognostizierte. Per Definition und Aufgabenstellung sind dies keine Prognosesysteme.

Das Potenzial der Quantile (P10, P50, P90): Meine Integration gibt Unsicherheitsfaktoren transparent an. Wer eine hohe Planungssicherheit benötigt, kann auf das unterste Quantil (P10) wechseln, was fast einer Ertragsgarantie entspricht. Wer das Beste aus beiden Welten möchte, kann P50 (Median) und P10 selbst mitteln und erhält eine extreme Sicherheit bei klarem Planungshorizont.

Das Problem in der Praxis: Das alles ist im System verbaut und bietet eine einzigartige Planungssicherheit ohne zu rollieren. Doch die Mehrheit der Nutzer möchte keine “Garantie”, sondern vergleicht lediglich die Treffergenauigkeit – und nutzt dieses Feature daher gar nicht für die eigene Energieplanung. Das zeigt auch der Post von @lemuba: Er nutzt den Median (P50), der naturgemäß einen deutlich größeren Unsicherheitsfaktor aufweist als P10 oder ein konservativer Mittelwert aus P50/P10.

Ich könnte einen zweiten Sensor bereitstellen, der nur die „garantierte Produktion“ ausgibt. Ich weiß aber genau, was passieren würde: Die Nutzer würden sich beschweren, dass die Prognose nicht zu 100 % trifft. Daher bleibt es ein Experten-Feature für diejenigen, die eine verlässliche, planbare Option benötigen und genau diese Einzigartigkeit schätzen.

Aber vieleicht sollte ich die Quantilen als Sensor bereitstellen… auch auf die Gefahr hin, dass es lange Diskussioinen geben wird.

3. Empfehlung

Die Materie ist hochkomplex und keine „Fire-and-Forget“-Lösung. Um die Funktionsweise besser nachvollziehen zu können, lies bitte die bereitgestellten Info-Texte im Forum. Dort sind die wissenschaftlichen Grundlagen detailliert aufbereitet.

Bitte verstehe mich nicht falsch: Ich fühle mich nicht angegriffen. Ich sehe lediglich, dass die methodischen Unterschiede noch nicht ganz durchdrungen wurden. Dein Vorschlag ist im Kern zwar der richtige Gedanke (Prognoselernen), wird der Realität aber in puncto Detailgenauigkeit und Belastbarkeit nicht ansatzweise gerecht.

Fazit:
SFML kann soviel mehr als auf den ersten Blick zu sehen ist. Es geht nicht um die Treffergenauigkeit auf dem Median.

Oh… definitely, even more: here you have what I believe is total cloud cover while some forecasts provide differentiation on: light, medium, heavy and also kind of total but unfortunately no API.

Die SFML Integration “ML Weather” zeigt dir auch, was SFML alles sieht.

und viel mehr

Ich werde es machen… Ich werde einen neuen Sensor einfügen, der NUR in Verbindung mit TFS und Quantilen einen Blend aus P10 (TFS) und P50 (SFML)
Bereitstellt und eine deutlich sichtbare Planungssicherheit prophagiert. Der Rest bleibt unangetastet. Er wird auch nicht in STATS eingebunden (aktuell) und ist speziell für alle die eine maximale, konservative Planungsgrundlage benötigen mit einer deutlich geschärften Präzision basierend auf " das kommt heute zu der Uhrzeit XY mit sehr hoher Wahrscheinlichkeit an" Es liegt in der Natur der Sache das dieser Sensor grunsätzlich konservativ ausfallen wird und NIEMALS 100% Treffer generieren wird. Das schafft sicherheit bei der Planung von WP, EV, SOC und weiteren Verbrauchern. Es wird aber Grundsätzlich unter dem P50 (Median) ausfallen.. das liegt in der Natur der Sache, da er die untere Sicherheit mit dem Median-Blend und dem Prognoseband blendet. → Es ist ein Sicherheitsnetz, dort wo es gebraucht wird.
Aktuell wird es bereits von einigen Usern genauso gemacht, in dem sie die DB nutzen um die Werte zu ziehen.. die ein hohes Maß an Planungssicherheit ab von Treffergenauigkeit benötigen. Lernen wird er nicht, da er bereits auf gelernte Daten zugreift.

@alteMade @lemuba @suedschwede @dietmar1968 → Feedback bitte!

Hi Tom,
Of course particles in the air will impact performance, same as air temperature, pressure etc etc however all this have minor impact maybe few % in comparison to outdated cloud cover which can reduce by 80-90% for heavy clouds.
By 20% kWp for heavy cloud in winter I meant that if you have 10kWp your daily production will be ~2kWh (+/- 1kWh) - it was just extreme condition based on recent winter, it was not simplification of your model - I know it’s significantly more complex.
With ”on a sheet of paper” I was referring to script that I made as a helper in HA that based on a geometrical data of your PV installation, geolocation and day of the year can generate hour PV forecast with accuracy +/- 0,1-0,2kWh for each hour including diffused radiation and with some additional effort - also shadows given by objects on the horizon - yes in a helper - I did it to have reference for further calculation that amplifies what open meteo returns (I see that open meteo forecast underestimate) with certain cloud cover.
My helper of course does not include that PV is covered in sahara dust nor temperature (open meteo does) nor pressure and is still quite accurate in most days.
In comparison, I had situation when for fully clear sky SMFL predicted >50kWh for my installation which is physically impossible based on system geometry and parameters - it’s not misunderstanding - there is an issue with forecast.

The other example was significantly underestimated or overestimated forecast but indeed maybe this was not caused by static approach but incorrect calculation after an update.

I never expect 100% accuracy - I know it’s impossible for any measurement not to mention forecast, especially not outside boundary condition (100% clear sky) but it’s good to try to predict as good as we have data.

I admit I’m still going through your posts with explanations, I probably didn’t go through all of them right now and if you are saying that rolling forecast will not have baseline to learn, and snapshot for learning is not the option than ok - you are the architect, as a user I can only propose suggestions and notify you about problems, I would really like to have solar forecast that I can fully count on it

wenn deine Vorhersage, so extrem Abweicht, bitte ich dich hierzu ein neues Thema zu eröffnen,
ggf. hast du etwas falsch konfiguriert.

If your prediction deviates so significantly, please start a new thread about it;
you may have configured something incorrectly.

I did Schlechterer Solar-Forecast nach Update & Zeitumstellung – DB bereinigen oder neu trainieren?

It seems that it is recovering slowly. As you see on a graph it was 85% then dropped. Although there might be two things to separate: model issue and weather dynamics as a different topic

@anon90989627
To clarify a few fundamental points where there seems to be a major misunderstanding:

1. “Outdated” Cloud Cover vs. Radiation Forecast The data is not outdated. Forecast data is fetched fresh and is accurate to the minute at the time of generation. More importantly: My model does not simply rely on “cloud cover.” It uses a learned radiation forecast for your specific location. I have explained this several times—it is a significant difference in how the physics of the model works.

2. Your HA Helper vs. This Model If your script—based on geometry and Open-Meteo—already yields an accuracy of +/- 0.1-0.2 kWh and even includes horizon shadows, then you have already built the perfect tool for your specific needs. Honestly, if it works that well for you, why not stick with it? It seems contradictory to look for another solution if yours is already “quite accurate most days.”

3. The Learning Process I’m struggling to see where the confusion lies regarding the “snapshot.” As I’ve mentioned, the system uses the actual live values (IST-Wert) for each hour and each panel group to learn. Specifically, it processes 23 different parameters per group, per hour. It is a continuous learning loop, not a static one-time calculation.

4. Forecast Deviations Regarding the case where it predicted >50kWh: If the physical geometry and parameters are set correctly, such a value shouldn’t be possible. This suggests a configuration issue or an incorrect sensor mapping on the user side rather than a “static approach” error. If a forecast is massively off after an update, it’s usually due to data feed changes or sensor mismatches, not the underlying logic.

I’m the architect of this system, and I’ve designed it to handle complexity far beyond simple geometry. If you want to use it, you have to trust the methodology; otherwise, your HA helper seems to be the better fit for your personal setup.

Topic of this thread is: How does it work i think it has been explained deep enogh so @Kaysen899 is right.. if you have deeper questions pls open a seperate Post and Mark it with EN for Example EN: Questions about Snapshots and XYZ ..

DEUTSCH:

Um einige grundlegende Punkte zu klären, bei denen anscheinend ein erhebliches Missverständnis vorliegt:

1. „Veraltete“ Bewölkung vs. Strahlungsprognose Die Daten sind nicht veraltet. Die Prognosedaten werden frisch abgerufen und sind zum Zeitpunkt der Erstellung minutengenau. Noch wichtiger: Mein Modell verlässt sich nicht einfach nur auf die „Bewölkung“. Es nutzt eine gelernte Strahlungsprognose für deinen spezifischen Standort. Ich habe das bereits mehrfach erklärt – das ist ein wesentlicher Unterschied in der physikalischen Arbeitsweise des Modells.

2. Dein HA-Helfer vs. dieses Modell Wenn dein Skript – basierend auf Geometrie und Open-Meteo – bereits eine Genauigkeit von +/- 0,1–0,2 kWh liefert und sogar Horizonteffekte (Schatten) einbezieht, dann hast du bereits das perfekte Werkzeug für deine Bedürfnisse gebaut. Ganz ehrlich: Wenn es für dich so gut funktioniert, warum bleibst du nicht dabei? Es wirkt widersprüchlich, nach einer anderen Lösung zu suchen, wenn deine eigene an den meisten Tagen „ziemlich genau“ ist.

3. Der Lernprozess Es fällt mir schwer nachzuvollziehen, wo die Verwirrung bezüglich des „Snapshots“ liegt. Wie erwähnt, nutzt das System die tatsächlichen Ist-Werte jeder Stunde und jeder Panelgruppe, um zu lernen. Konkret werden 23 verschiedene Parameter pro Gruppe und Stunde verarbeitet. Es handelt sich um eine kontinuierliche Lernschleife, nicht um eine statische Einmalberechnung.

4. Prognoseabweichungen Zu dem Fall, in dem >50 kWh vorhergesagt wurden: Wenn die physische Geometrie und die Parameter korrekt eingestellt sind, ist ein solcher Wert unmöglich. Das deutet eher auf ein Konfigurationsproblem oder ein falsches Sensor-Mapping auf Nutzerseite hin als auf einen Fehler im „statischen Ansatz“. Wenn eine Prognose nach einem Update massiv danebenliegt, liegt das meist an Änderungen im Datenfeed oder an nicht passenden Sensoren, nicht an der zugrunde liegenden Logik.

Ich bin der Architekt dieses Systems und habe es so konzipiert, dass es Komplexitäten bewältigt, die weit über einfache Geometrie hinausgehen. Wenn du es nutzen möchtest, musst du der Methodik vertrauen; andernfalls scheint dein HA-Helfer die bessere Wahl für dein persönliches Setup zu sein.

Das Thema dieses Threads ist: „Wie funktioniert es?“. Ich denke, das wurde nun tiefgreifend genug erklärt, und @Kaysen899 hat recht. Falls du tiefergehende Fragen hast, öffne bitte einen separaten Post und markiere ihn zum Beispiel mit „EN: Questions about Snapshots and XYZ“.

Reg. 1. SFML takes latest weather forecast for specific hour but at the very morning and it is basically fixed for the rest of the day. So for dynamically changing weather forecast taken at 6am might be outdated at 11am, correct?

Reg. 2. My helper is able to achieve 0,1-0,2 deviation only for fully clear sky and improve accuracy of open meteo. I never stated that it has this accuracy for entire day, entire year in all conditions

Nevertheless it was still more accurate for most of the days for the past month then dropping in accuracy SFML after the update

Reg. 3 “continues learning loop” but once a day, every day during night and morning routine, correct?

Reg. 4 again, geometrical nor electrical parameters were changed but accuracy dropped from 85% to below 70% in a month after the update. Moreover you cross checked them in a log file with no issue.

  1. No you are not correct
  2. okay understood
  3. No EOD is the learning task and samples will be collected the whole day (group, hour, radiation, temp, wind, weather,… 23 total)
  4. yes / no you startet the dev-services (they have a clear warning not to use them - they are destructiv) you have destroyed your database / ai doing so - as explained to you. but after restore form a previous backup everything seems fine (again). → as mentiond “if there is still a problem” i need the log files after 3 days starting from scratch or backup / restore.

I close it for now.. because there is a second thread and that´s the right place for it.. i don´t mean it in rude way! everyone is suportiv but it is hard to track problems across multiple threads!

@Kaysen899 Nun hast Du mehr Kontext!

2 „Gefällt mir“

Ich bin zwr nicht genannt, kann aber mit dem p10 richtig was anfangen, weil ich gerade heute herausgefunden habe, wie ich bei der WP den Heizstab only einsetzen kann. Bedeutet für mich, dass ich mir da eine prima Automation basteln kann und von dem Fronius Lastmanagement flexibler und unabhängiger werde! Besten Dank!

So habe ich mir das vorgestellt! :robot:

Ich habe es eingebaut… aber bitte daran denken, es ist die Minimal-Erwartung also was auf jeden Fall “reinkommt”.. keine Prognose wie der Median von SFML

1 „Gefällt mir“

Nur nebenbei, ich würde es begrüßen wenn hier im Forum wieder ausschließlich deutsch kommuniziert würde. Vielen komplizierten Themen kann ich persönlich nur schlecht folgen.
Herzlichen Dank!

3 „Gefällt mir“

Deswegen mein Hinweis “mach bitte ein Thema auf mit EN als Info, sollte es Sprachprobleme geben” die Vermengung von De und En ist nicht akzeptabel.. das zerstört Lesefluss und sperrt andere aus… außerdem sollte es zwingend die Ausnahme bleiben!!! Es gibt genügend Übersetzungstools um hier in Deutsch zu posten!

1 „Gefällt mir“

Leute, ganz ruhig. Es gab eine hitzige Diskussion, deshalb bin ich auf Englisch umgestiegen.

Falls das ein Problem darstellt, entfernt diesen Teil bitte.

Moin,

ich will mich auch nochmal für die Möglichkeit einer rollierenden Vorhersage stark machen, muss aber zugeben, dass ich noch nicht alles von gestern und heute gelesen habe.

Beispiel:

Ich nutze die Vorhersage zur Zeit zur Steuerung meiner Haus Akku Ladung und Wallbox Steuerung. So lasse ich z.B. im einfachen Fall meinen Akku nur langsam laden bis 90% und erst abend wenn die Restvorhersage unter einen bestimmten Wert gesunken ist wird dieser nochmal auf 100% gebracht um so 1) den Akku durch langsameres laden zu schonen und auch zu vermeiden dass der akku sehr lange bei 100% rumsteht was der Zellchemie auch nicht gut tut. Insbesondere für den letzten 100% Kick ist mir eine genaue vorhersage des Tagesrestes wichtig. Da bringt es mir nicht, dass SFML morgens um 6 Uhr was berechnet hat, ich brauche Nachmittags eine gute Restvorhersage. Zu sehen wie toll die Prognosegenauigkeit des System ist, ist da eher akademischer Natur, für eine Automatisierung aber suboptimal.

Macht ja nix, Du hast ja uns :hugs:

So, nun bin ich auch durch mit dem Lesen… das mit dem p10 wäre eine Möglichkeit. Da könnte man sich dann selbst dem Rest des Tages Wertes mit ausrechnen (p10-bereits erzeugt). Das sollte evtl gehen, mal schauen.

@Heatseeker @Joachim-xo @Kaysen899 @dietmar1968 @alteMade

Hinweis zur Prognose – SFML & TFS

Damit keine falschen Erwartungen entstehen und die Diskussion in die richtige Richtung geht, möchte ich einige Grundlagen erläutern. Diese Erklärung gilt ausdrücklich nur für SFML und TFS – ich bin mir bewusst, dass andere Systeme dies anders handhaben oder gar nicht erst anbieten.

Was ist eine Prognose?

Eine Prognose ist ein sogenanntes Prognoseband, das aus drei Werten besteht:

  • P10 = untere Grenze → tritt mit sehr hoher Wahrscheinlichkeit mindestens ein
  • P50 = wahrscheinlichster Wert (Median)
  • P90 = obere Grenze → tritt ein, wenn alle Bedingungen optimal sind

Wie funktioniert der Prognosesensor in SFML?

SFML liefert P50 (Median) als Rohwert. Das Modell gewichtet dabei – basierend auf historischen Daten und kontinuierlichem Lernen – verschiedene Layer unterschiedlich, abhängig von Faktoren wie Uhrzeit, Sonnenstand, Jahreszeit, Wetterlage und Anlagenkonfiguration. Die Gewichtung erfolgt stündlich.


Was sind Layer?

Vereinfacht gesagt sind Layer die einzelnen KI-Modelle innerhalb des Hubble-Stacks (u. a. Physics, RIDGE …). Jedes Modell betrachtet einen Teilbereich und kommt daher zu einer eigenen Einschätzung. Die Gesamtkomplexität erfasst nur das übergeordnete KI-System. TFS hingegen arbeitet mit einer eigenständigen Logik und nutzt keine externen Layer.

Wie entstehen die Quantile (P10 / P90)?

Das Modell schätzt aus Erfahrung den möglichen Minimal- und Maximalwert und kombiniert diese mit gelernten Mustern. Daraus ergibt sich der Median (P50) – gleichzeitig kennt das Modell naturgemäß auch P10 und P90.

Wie nutzen erfahrene Anwender P10?

Einige Nutzer setzen seit den ersten Tagen auf die Kombination Median + P10, also die KI-Schätzung gemeinsam mit dem Wert, der mit sehr hoher Wahrscheinlichkeit mindestens erreicht wird, um ihr Energiemanagement darauf aufzubauen. Sie wissen, dass der tatsächliche Ertrag in 9 von 10 Fällen deutlich darüber liegen wird – und dass P10 keine klassische Prognose ist. Der Vorteil: ein verlässlicher Planungshorizont auf Basis eines Szenarios, das mit sehr hoher Wahrscheinlichkeit eintreten wird, während der tatsächliche Ertrag häufig deutlich darüber liegt.

Der neue „konservative" P10-Sensor

Da mich mehrere E-Mails erreicht haben und das Thema auch im Forum wiederholt aufgekommen ist, habe ich eine abgestimmte Variante des P10-Werts als Sensor implementiert.

Funktionsweise: Der P10-Wert aus TFS und SFML wird überlagert, anschließend wird der Median von SFML im Verhältnis 65/35 darübergeblendet. Das Ergebnis ist ein konservativer, aber sehr verlässlicher Stundenwert sowie Tageswert, mit dem konkret geplant werden kann – jedoch deutlich zurückhaltender als der reine SFML- oder TFS-Wert.

Nutzen: Wenn ich weiß, dass ich heute unter allen Umständen mindestens X kWh erzeugen werde, oder dass in Stunde XY definitiv X kWh am Wechselrichter anliegen werden, verschafft mir das einen erheblichen Planungsvorteil im Energiemanagement.

Praxisbeispiel

Wert
SFML-Prognose (heute) 13,8 kWh
P10 (heute) 9,23 kWh
IST (heute) 10,1 kWh

Erklärung der Abweichung: Die Differenz zum SFML-Wert ist auf MPPT-Throttling zurückzuführen – SFML hat keine fehlerhafte Prognose geliefert. Im Gegenteil: Die bereinigte Trefferquote liegt bei 92,3 %, was beeindruckend ist – für die operative Energieplanung aber nur begrenzt hilfreich ist.

  • Geplant auf SFML-Basis → Abweichung: 3,7 kWh
  • Geplant auf P10-Basis → Abweichung: 0,87 kWh

Fazit

P10 und P90 sind keine Prognosen, sondern statistische Annahmen – und genau darin liegt ihr enormer praktischer Wert für Planung und Lastmanagement.

ZARA

PS: Ich habe den Wert bisher bewusst nicht als Sensor bereitgestellt, da er sich nicht intuitiv erschließt und ich befürchtet habe, er würde als reguläre Prognose missverstanden werden. P10 ist ein klassischer Kennwert der Energiewirtschaft zur Kapazitäts- und Lastplanung. → es geht also über die “normale” Solarprognose hinaus und Bedarf ein Grundverständnis.
Auch ist es ein erster Aufschlag, ich bin überzeugt davon das ich den Blend im laufe des Jahres noch anpassen muss.. vermutlich 80/20

Fun-Fact: Er ist bereits in den Statistiken der Jahresprognose enthalten – und ist niemandem aufgefallen. Stattdessen ist genau das eingetreten, was ich befürchtet hatte: Der Wert wurde diskutiert und mit Vorjahreswerten verglichen - was keinen mathematischen Sinn ergibt.

Ich denke das Ralf und Dietmar aus ihrem Fachwissen noch einiges dazu beisteuern können, sollte ich etwas vergessan haben…

3 „Gefällt mir“