Residuallast-Frühwarnung: 5 Tage Vorlauf vor teuren Tagen — Methodik-Check erbeten

Darius75 · 16. August 2026 um 11:25

Hallo zusammen,

ich habe mir eine Vorwarnung vor teuren Strom-Tagen gebaut und würde die Methodik gern von euch prüfen lassen. Weil ich etwas schreibfaul bin habe ich den nachfolgenden Text zum großen Teil mit Hilfe von AI schreibe lassen...
Das Skript läuft, ich habe es gegen 45 Tage Ist-Daten validiert — und weiß jetzt ziemlich genau, wo die Schwachstellen liegen. Bei den offenen Punkten (siehe unten) hätte ich gern euren Rat.

Warum das Ganze?

Mein Energiemanagementsystem (EOS) optimiert Day-Ahead, sieht die Preise also erst ~24–48 h vorher. Für die richtig interessanten Entscheidungen ist das zu spät: Wenn übermorgen eine Dunkelflaute ansteht, will ich heute schon wissen, dass ich das Auto noch mit PV-Überschuss vollladen und den Hausspeicher vollhalten sollte. Die Warnung sitzt deshalb eine Ebene über dem EOS. Sie steuert (noch) nichts, sie sagt nur: „Bereite dich vor.“

Mein Setup: 12,75 kWp PV (Ost/West), E3/DC S10E 19,66 kWh, VW ID.3 (55 kWh) an 11-kW-Wallbox, Tibber-Tarif.

Wie das Modell rechnet

Die zentrale Kenngröße ist die Residuallast (Last minus Erneuerbare), nicht der Erneuerbaren-Anteil an der installierten Leistung. Das Modell rechnet alle 6 Stunden wie folgt:

Wetterdaten (Open-Meteo): 5-Tages-Prognose an 6 Knotenpunkten in DE (Nord/Küste, Ostsee, Hannover, NRW, Frankfurt, München). Genutzt werden shortwave_radiation und wind_speed_100m mit festen Gewichten (Summe je 1,0).
Kapazitätsfaktoren (CF):
- Solar: linear aus der Globalstrahlung, gedeckelt bei 850 W/m².
- Wind: über eine vereinfachte Leistungskurve (unter 3 m/s null, ab 12 m/s Volllast, dazwischen kubisch, Cut-out ab 25 m/s).
Hochrechnung auf DE: 128 GW PV (DC), 70,6 GW Wind Onshore + 10,9 GW Offshore, plus 6,5 GW Sockel (Biomasse/Wasser/Müll). Werte stammen aus api.energy-charts.info/installed_power. Der Sockel ist die gemessene mittlere Erzeugung, nicht die installierte Leistung. Wichtig: Dazu kommen Flottenfaktoren von 0,46 für Solar und 0,44 für Wind (dazu unten mehr – das war mein größter Fehler).
Lastprofil: Ein Stundenprofil, rollierend gebildet aus der gemessenen Last der letzten 30 Tage (Energy-Charts public_power, Reihe Load), getrennt nach Werktag und Wochenende. So passt es sich der Jahreszeit automatisch an.
Kalibrierung: Abgleich gegen ren_share_forecast von Energy-Charts, damit der Erneuerbaren-Anteil der ersten 24 Stunden zur Realität passt.
Preiskorridore: Bänder für die Tages-Spitzenresiduallast, gefittet gegen Ist-Preise:
- < 33 GW = günstig
- 33–42 GW = normal
- 42–46 GW = erhöht
- > 46 GW = hoch

Erkenntnisse aus der Validierung (45 Tage)

Geprüft habe ich gegen gemessene Residuallast und Ist-Börsenpreise.

Ergebnis 1: Das Grundkonzept trägt.

Korrelation der gemessenen Residuallast mit dem Preis:

Spitze vs. Tages-Höchstpreis: r = +0,56
Spitze vs. Tages-Mittelpreis: r = +0,79
Mittel vs. Tages-Mittelpreis: r = +0,86

Ergebnis 2: Das Modell schlägt die Messwerte.

Das Modell sagt den Preis sogar etwas besser voraus als die gemessene Residuallast (r = +0,62 beim Höchstpreis, r = +0,89 beim Mittelpreis). Klingt paradox, ist aber physikalisch plausibel: Das Modell glättet lokale Extreme, und geglättete Größen korrelieren oft besser mit dem überregionalen Strompreis als verrauschte Ist-Reihen.

Warnung vor zwei Fehlern, die sich gegenseitig verstecken

Beim Nachrechnen fiel ein Versatz auf. Die Suche förderte zwei grobe Schnitzer zutage, die sich fatalerweise im Verhältnis fast exakt aufhoben:

Das Lastprofil war 8–10 GW zu hoch (stundenabhängig: nachts nur −2,3, abends bis −13,4 GW Abweichung zur gemessenen Last).
Die Erzeugungs-Obergrenzen lagen bei rund dem Doppelten der Realität:
- Solar: Modell-Max 108,8 GW vs. gemessen 58,5 GW (Faktor 1,86×)
- Wind: Modell-Max 81,5 GW vs. gemessen 35,6 GW (Faktor 2,29×)

Warum? Bei Solar erreicht min(GHI/850, 1) im Sommer im Modell regelmäßig 100 %. Eine reale DE-weite Anlage liefert aber nie ihre DC-Nennleistung (Temperatur, Anstellwinkel, Wechselrichter-Kappung). Gemessene Spitze / installierte DC-Leistung = 58,5 / 128 = 0,46. Bei Wind bedeuten sechs Stützpunkte auf Volllast im Modell gleich Volllast der ganzen deutschen Flotte. Real glättet die räumliche Verteilung das massiv weg (35,6 / 81,5 = 0,44).

Weil beide Fehler in dieselbe Richtung wirkten, stimmte das Verhältnis Last/Erneuerbare und die Residuallast sah auf den ersten Blick brauchbar aus. Aufgeflogen ist das erst, als ich das Lastprofil allein korrigiert habe. Tipp an alle Bastler: Prüft eure Obergrenzen immer gegen die echten Maxima aus public_power!

Wo ich euren Rat bräuchte

Lastprognose: Mein rollierendes 30-Tage-Profil ist besser als ein statisches, bleibt aber ein Mittelwert ohne Kenntnis von Temperatur oder Feiertagen. Die modellierte Tagesspitze liegt dadurch systematisch zu niedrig. Kennt jemand eine freie Lastprognose für DE mit mehr als 24 h Horizont? ENTSO-E hat Day-Ahead, für längere Zeiträume habe ich nichts gefunden.
Kalibrierung über den Horizont: Mein Kalibrier-Anker stammt aus den ersten 24h und wird dann auf alle 5 Tage angewendet. Getestet habe ich drei Regeln, am besten funktionierte es, den (gut bekannten) Sockel unskaliert zu lassen. Trotzdem wird der Anker für Tag 3–5 relativ dünn. Wie würdet ihr das skalieren?
Spitze vs. Mittelwert: Ich bande aktuell auf die Tagesspitze, obwohl das Tagesmittel (r = +0,89) eigentlich der bessere Prognostiker ist. Das Problem: Die Prognosewerte des Mittels liegen derzeit über dem Bereich, auf dem ich fitten konnte. Das Modell sagt dann pauschal „hoch“ und trennt nicht mehr sauber. Die Spitze bleibt im belegten Bereich. Würdet ihr trotzdem auf das Mittel gehen und die Unsicherheit/Extrapolation in Kauf nehmen?
Winter-Dunkelflaute fehlt in den Daten: Die Warnschwelle (42 GW) sticht gut heraus. ABER: Der Fit sitzt aktuell auf 45 Sommertagen. Mein echter Zielfall (die Winter-Dunkelflaute) kam im Datensatz kein einziges Mal vor. Hat jemand von euch schon mal die Residuallast gegen Day-Ahead-Preise über ein volles Jahr gelegt?
Kuppelstellen & Must-Run: Im-/Export, Must-run konventionell und Pumpspeicher ignoriere ich derzeit komplett. Für eine grobe Ampel-Funktion vertretbar, oder unterschätze ich den Impact massiv?
Die Grundsatzfrage (EpexPredictor): Es gibt mit dem EpexPrediktor bereits eine offene, KI-basierte (LightGBM) Mehrtages-Preisprognose. MAE 1,73 ct/kWh für DE, 5 Tage im 15-Min-Raster. Lohnt sich mein rein physikalischer Ansatz da überhaupt noch? Meine Hoffnung: Da mein Modell physikalische Ursachen abbildet statt Muster zu lernen, könnte es bei untypischen Wetterlagen (außerhalb der Trainingsdaten) robuster sein. Hat jemand die beiden Ansätze (KI vs. Physik) über einen Winter verglichen?

(Das Skript ist ein einzelnes, schlankes Python-File ohne große Fremdbibliotheken. Bei Interesse stelle ich es gern hier rein!)

Ich freue mich auf euren Input!

Viele Grüße

ironmaster · 16. August 2026 um 11:49

Hast du die Möglichkeit deine Prognose Daten auch historisch zu beziehen?

Das würde es ermöglichen zu bestimmen wie gut dein Modell rechnet anhand einem "Korrektur-Lauf" von Prognose zu echten Daten.

Und zweitens könnte man damit auch Feiertage und Wochenenden modellieren können.

Ganz grundsätzlich für die Dunkelflaute Warnung sollte ein Algorithmus basierter Ansatz anhand Messdaten eigentlich mehr als ausreichend sein.

Wenn man nicht gerade im MWh Bereich Akkukapazität vorhält, ist der Hebel eh relativ gering.

Bei deinem Setup ist ja so ziemlich die einzige Stellschraube das Auto aus dem Netz zu laden anstatt PV, wenn der dynamische Strompreis günstiger ist wie der Netzbezug und die PV Prognose deinen Speicher nicht füllen könnte.

Wie sieht es denn auf der Verbrauchseite aus?
Da macht auch nochmal einen Unterschied ob man am Tag nur 5kWh braucht oder 50 weil strombasiert geheizt wird.

Wie sieht's mit dynamischen Netzentgelten bei deinem Netzbetreiber aus? Das wäre auch nochmal ne Stellschraube.

Darius75 · 16. August 2026 um 16:49

Kurzer Nachtrag, weil sich aus deiner Frage nach den historischen Daten mehr ergeben hat als erwartet — und weil ich deinem Punkt zum Hebel noch ein Hinweis geben möchte.

Zum Hebel: die Wärmepumpe ist der Grund. Du schreibst, die einzige Stellschraube bei meinem Setup sei das Auto aus dem Netz statt aus PV zu laden. Im Sommer und den Übergangszeiten stimmt das sogar noch weiter gehend — da gibt es gar nichts zu optimieren da bin ich fast die ganze Zeit bei 99 % Autarkie.

Im Winter kippt es komplett: 35,7 kWh/Tag Netzbezug im Januar, 5,9 % Autarkie. Und dort ist das Auto nicht die relevante Größe, sondern die Wärmepumpe — sie macht den Großteil der 34–42 kWh/Tag aus.

Der entscheidende Unterschied: Das Auto und noch andere Verbraucher kann ich verschieben, die Wärmepumpe nicht. Die läuft, wenn es kalt ist, nicht wenn der Strom billig ist. Genau deshalb lohnt es sich für mich, den Speicher vor einem teuren Tag voll zu lassen statt ihn abends normal leerzufahren — er ist das einzige Instrument, mit dem ich den nicht steuerbaren Verbrauch aus dem teuren Fenster heraushalten kann. 19kWh decken bei Winterlast etwa einen halben Tag; das reicht, um die Spitzen zu überbrücken.

Das ist der eigentliche Zweck der Warnung: nicht nur das Auto optimieren, sondern rechtzeitig wissen, dass ich den Speicher nicht wie sonst verbrauchen sollte. Ich bin mal gespannt wie sich die dynamischen Strompreise im kommenden Winter entwickeln werden. Vor allem wie teuer die Spitzenzeiten sein werden...

chloe-price · 13. November 2026 um 10:13

Hallo Darius,

danke für dein Beitrag, eigentlich wollte ich dir nur etwas Rückmeldung geben und deine Ergebnisse durchrechnen, aber dein Beitrag war der Anstoß für ein Projekt, dass ich die letzten ein zwei Tage fortgeführt habe und noch eigene Ideen eingebracht habe wie ein größeres Raster über Deutschland sowie die Fossilen Rohstoffpreise noch zu berücksichten.
Da ich dein Modell nicht als script hatte, habe ich das kurzerhan einfach mal claude gegeben mit den erweiterungen, daher folgt hier auch die KI Antwort auf deine Fragen sowie auf die Antworten von @ironmaster:

Zu deinen Fragen

Lastprognose > 24 h: Eine freie habe ich auch nicht gefunden. Die Last wird deshalb gelernt: aus Stunde, Wochentag, Feiertag, Temperatur an 8 Ballungsräumen und dem Lastniveau der Vorwoche.
Kalibrierung über den Horizont: Statt eines Ankers nutze ich historische Prognosen, so wie @ironmaster es vorgeschlagen hat. Die Open-Meteo Previous Runs API liefert die damaligen ECMWF-Prognosen je Vorlauf ab März 2024. Damit lässt sich je Vorlauf ein Modell trainieren und ehrlich testen; es lernt selbst, wie unsicher Tag 3–5 ist.
Spitze oder Mittel: Das Mittel, und vor allem relativ eingestuft statt mit festen GW-Grenzen. Das war der größte Einzelschritt, siehe unten.
Ganzes Jahr / Winter: Deine Sommerbeobachtung bestätigt sich. Gemessene Residuallast (Tagesmittel) gegen Tagesmittelpreis ergibt von Nov. 2024 bis Okt. 2025 r = 0,90. Von Nov. 2025 bis Nov. 2026 waren es aber nur noch 0,55, im Winter rund 0,5. Der Grund ist der Gaspreis, der sich zwischendurch verdoppelt hat: gleiche Residuallast, anderer Preis.
Import/Export, Must-run, Pumpspeicher: Die sind auch im erweiterten Modell nicht explizit drin; sie bleiben im Restfehler.
KI vs. Physik (EpexPredictor): Den habe ich nicht verglichen. Verglichen habe ich mit der Holt-Winters-Fortschreibung, die EOS und DVhub nutzen, wenn keine Börsenpreise mehr da sind.

Dein Modell im Rückblick (Nachbau, explorativ)

Nachgebaut nach deinem Beitrag:

6 Knoten (jeweils der nächste Gitterpunkt, gleich gewichtet; deine Gewichte kenne ich nicht)
Strahlung/850, gedeckelt bei 1
Windkurve 3/12/25 m/s
Flottenfaktoren 0,46/0,44
Sockel 6,5 GW
30-Tage-Lastprofil, getrennt nach Werktag und Wochenende
Bänder 33/42/46 GW auf die Tagesspitze

Deine ren_share-Kalibrierung gibt es nicht als Historie. Ersatzweise bekommen Wind und Solar je Tag einen Faktor aus den letzten 30 Tagen (nur Vergangenheit).

Ergebnisse für das zweite Jahr (Nov. 2025 – Nov. 2026), 2–5 Tage Vorlauf:

Teure Tage (Tagesmittel über dem 80-%-Quantil der letzten 28 Tage), F1-Wert: dein Ansatz 0,50, Holt-Winters 0,38. Dein Ansatz liegt damit vor der reinen Preis-Fortschreibung, statistisch aber noch nicht gesichert (Differenz +0,12, 95-%-Intervall −0,04 bis +0,22; im ersten Jahr ähnlich).
Die feste 42-GW-Schwelle ist saisonabhängig: Im Winter erkennt sie 75–88 % der teuren Tage, warnt dafür aber an 57–61 % aller Tage. Im Sommer erkennt sie nur 36–47 %.
Selbst mit perfekt bekannter (gemessener) Residuallast kommen die festen Bänder nur auf F1 0,61–0,63. Das ist die Obergrenze des Band-Ansatzes, egal wie gut die Wetterprognose ist.
Ohne Kalibrierung ist der Wind im Mittel etwa um den Faktor 2,8 zu niedrig. Der Flottenfaktor aus der Spitze drückt auch das Mittel, und 4 der 6 Knoten liegen im Binnenland. Die Residuallast liegt dann ~10 GW zu hoch, und es wird an ~70 % der Tage gewarnt. Deine Kalibrierung ist also wichtig, oder deine Gewichte sind küstenlastiger als meine Annahme.

Wo ich abgebogen bin, was dazukam und was jeder Schritt bringt

Alle Schritte laufen auf denselben Tagen, Tag 2–5 zusammen, im zweiten Jahr (in Klammern: das ruhige erste Jahr Nov. 2024 – Okt. 2025):

Schritt	Teure Tage (F1)	Residuallast-Fehler	Preisfehler je Stunde
1 Nachbau deines Modells	0,50 (0,47)	9,0 GW (8,6)	–
2 + 42 Gitterpunkte statt 6 Knoten, Wind/Solar je Vorlauf gelernt, Lastmodell mit Temperatur und Feiertagen; weiter mit der 42-GW-Schwelle	0,54 (0,49)	5,5 GW (5,5)	–
3 + relative Einstufung: Residuallast-Tagesmittel über dem 80-%-Quantil der letzten 28 Tage	0,62 (0,61)	5,5 GW	–
4 + Preismodell nur aus der Residuallast	0,35 (0,57)	–	4,0 ct (2,3)
5 + Preisniveau der Vorwoche	0,56 (0,61)	–	2,8 ct (2,3)
6 + Gas, CO₂ und Brent	0,60 (0,62)	–	2,6 ct (2,3)
7 + Preis relativ zu den Grenzkosten eines Gaskraftwerks = erweitertes Modell (live)	0,66 (0,59)	–	2,4 ct (2,4)
Holt-Winters (EOS/DVhub)	0,38 (0,38)	–	3,7 ct (3,2)

Was ich daraus lese (95-%-Intervalle per Block-Bootstrap über 30-Tage-Blöcke):

Der größte Einzelschritt ist die relative Einstufung (Schritt 3 gegen 1: F1 +0,12 im zweiten Jahr, Intervall +0,02 bis +0,22; im ersten Jahr +0,17). Deine Residuallast-Idee mit gelernter Umrechnung und relativer Schwelle kommt ganz ohne Preismodell auf 0,62.
Das erweiterte Modell liegt bei den teuren Tagen nur knapp darüber (+0,04, Intervall −0,04 bis +0,12, also nicht gesichert; im ruhigen Jahr sogar −0,02). Gegenüber dem Nachbau sind es +0,16 (+0,08 bis +0,25), gegenüber Holt-Winters +0,25.
Wozu dann das Preismodell? Es liefert Stundenpreise mit Band P10–P90, die DVhub für die Speicher- und Ladeplanung braucht (2,4 ct/kWh Fehler gegenüber 3,7 bei Holt-Winters).
Vorsicht bei Preismodellen ohne Preisniveau: Schritt 4 bricht in der Gasphase ein (F1 0,35, 4,0 ct), schlechter als dein Nachbau. Erst Preisniveau und Brennstoffpreise machen es robust; das Preisniveau bringt dabei den größten Teil.
Außerdem dazugekommen: Live-Wetter aus ECMWF Open Data, weil die freie Open-Meteo-API nur nichtkommerziell ist. Modellwahl nach einer vorher festgelegten Regel. Das Modell ist jetzt eingefroren und wird ab sofort laufend an den echten Börsenpreisen gemessen, also daran, wie gut es in der Zukunft abschneidet und nicht nur im Rückblick.

Zum Hebel: @ironmaster hat für reine Arbitrage recht. Bei einem schnell zyklierenden Speicher bringen die Tage 2–5 gegenüber „nur morgen planen“ kaum etwas: +0,2 €/Jahr bei 10 kWh, +6 €/Jahr bei 77 kWh, beides nicht signifikant. Eine schlechte Mehrtagesprognose kostet dagegen (Holt-Winters −15 bzw. −108 €/Jahr). Dein Fall mit der nicht verschiebbaren Wärmepumpe, bei dem du den Speicher vor teuren Tagen vollhältst, ist ein anderer. Den habe ich noch nicht gerechnet, und genau dort sollte die Vorwarnung mehr wert sein

Ende der Ki Formulierten antwort

Ich habe wie oben geschrieben also das Modell noch erweitert und mit den ECMWF Prognosen der letzten 2 Jahre auf meinem Mac Studio noch durchprügeln lassen sowie dann um Öl und Gaspreise sowie Kraftwerksgrenzkosten erweitern lassen und die Installations Zahlen der zugebauten Leistung noch einbauen lassen, das ganze ist jetzt inzwischen soweit dass ich es als Tool auf meiner freien Tools Seite online gestellt habe wo es jeder gerne abrufen und nutzen kann. Wie viel das dann im folgenden Jahr bringt wo wir keine Daten haben, darauf bin ich gespannt wie gut das abschneidet in der Zukunft.

Das erweiterte Modell läuft jetzt live auf DVhub Online, mit Verweis auf dich und diesen Thread als Ursprung der Idee.
Die Prognose gibt es auch als JSON: https://dvhub.online/v1/residual-load/outlook

Hast du evtl lust hier mal dein Script zu teilen um das noch besser vergleichen zu können ?

Danke für den Anstoß!

Viele Grüße
Christin

Hier noch ein paar Diagramme mit den Ergebnissen

Darius75 · 13. November 2026 um 13:25

Hallo Christin,

danke, das ist deutlich mehr, als ich mir von einem „Methodik-Check" erhofft hatte. Zwei Jahre Rückblick mit echten Vorlauf-Prognosen ist genau das, was mir fehlt: Mein Fit saß auf 45 Sommertagen. Ich habe deine Kernaussagen gegen mein Live-Protokoll gelegt. Das läuft seit dem 16.08. und schreibt täglich mit, was der Detektor für die nächsten Tage vorhergesagt hat (89 Lauftage, Vorlauf 0–4).

## Vorweg: was sich bei mir seit dem Beitrag geändert hat

Nach der Rückfrage von @ironmaster habe ich die Bänder als Auslöser aufgegeben. Der Alarm hängt seitdem an einem ICON-EPS-Ensemble mit 40 Mitgliedern und löst aus, wenn mindestens 70 % der Mitglieder über 42 GW Tagesspitze liegen. Die Schwelle selbst ist aber fest geblieben, und genau da trifft deine Kritik.

## Abgleich mit meinen Live-Daten

Ich habe deine Definition übernommen: Teuer ist ein Tag, dessen Tagesmittelpreis über dem 80-%-Quantil der letzten 28 Tage liegt. Ausgewertet sind Vorlauf 2–4 Tage vom 15.09. bis 12.11., das sind 171 Prognose/Ist-Paare an 58 Tagen. Die relative Einstufung vergleicht jede Prognose mit den Prognosen gleichen Vorlaufs der 28 Tage davor.

|---|---|---|---|---|

| fest: Spitze ≥ 42 GW (deterministisch) | 0,76 | 0,77 | 0,76 | 43 % |

| Ensemble ≥ 70 % über 42 GW (mein Live-Alarm) | 0,70 | 0,73 | 0,66 | 39 % |

| relativ: Spitze über P80 (28 Tage) | 0,69 | 0,81 | 0,59 | 32 % |

| **relativ: Tagesmittel über P80 (28 Tage)** | **0,79** | **0,90** | 0,70 | 34 % |

| EpexPredictor, Tagesmittel über P80 der Ist-Preise | 0,83 | 0,83 | 0,84 | 44 % |

Was ich daraus lese:

- **Relativ und Mittel bestätigt sich**, bei mir aber mit kleinerem Abstand als bei dir. Gegen die feste Schwelle sind es +0,03 (95-%-Intervall −0,02 bis +0,10, Block-Bootstrap über 14-Tage-Blöcke), also nicht gesichert. Gegen meinen Ensemble-Alarm sind es +0,09 (+0,03 bis +0,26). Der sichtbare Gewinn liegt in der Präzision: 0,90 statt 0,77 bei weniger Warnungen.

- **Die Saisonabhängigkeit der 42 GW sehe ich live.** Über alle Vorläufe lag der Ensemble-Alarm im September an 22 % der Paare über der Schwelle, im Oktober an 30 %, im November bisher an 71 %. Das passt zu deinen 57–61 % im Winter.

- **Unbequem für mich:** Mein Ensemble-Alarm schneidet schlechter ab als die schlichte deterministische Schwelle. Das Ensemble bringt eine ehrliche Unsicherheitsangabe, als Auslöser gegen eine feste GW-Grenze hat es in diesem Zeitraum aber nichts gebracht.

- **Zu Frage 6, die du nicht gerechnet hast:** EpexPredictor liegt bei 2–4 Tagen Vorlauf mit 0,83 leicht vor der relativen Residuallast, gesichert ist das nicht (Differenz −0,04, Intervall −0,09 bis +0,16). Bei der Korrelation mit dem Tagesmittelpreis ist es bei Vorlauf 2 vorn (0,91 gegen 0,88), bei Vorlauf 3 und 4 gleichauf (0,87 gegen 0,89 und 0,84 gegen 0,85).

Eine Einschränkung zur Vergleichbarkeit: In meinem Zeitraum gelten 25 der 58 Tage als teuer, nicht 20 %. Die Preise sind von September bis November durchgehend gestiegen, und ein nachlaufendes 28-Tage-Quantil hinkt einem Trend hinterher. Meine F1-Werte liegen deshalb höher als deine und sind nur untereinander vergleichbar. Hast du in deinen zwei Jahren geprüft, wie stark die Quote der „teuren" Tage zwischen den Jahreszeiten schwankt?

## Gaspreis: bei mir als Niveauverschiebung sichtbar

Die gemessene Residuallast (Tagesmittel) gegen den Tagesmittelpreis ergibt bei mir von Juli bis Mitte November r = 0,93 (135 Tage) und je Monat 0,81 bis 0,96. Deinen Einbruch auf 0,55 sehe ich in diesen viereinhalb Monaten nicht. Das widerspricht dir nicht, mein Fenster ist dafür zu kurz. Die Verschiebung selbst ist aber da:

| Residuallast (Tagesmittel) | Juli/August | Oktober/November |

|---|---|---|

| 15–25 GW | 118 EUR/MWh (n=31) | 156 (n=8) |

| 25–35 GW | 147 (n=14) | 187 (n=9) |

Gleiche Residuallast, rund 40 EUR/MWh mehr. Innerhalb eines Monats bleibt die Rangfolge stabil, über die Monate driftet das Niveau. Das spricht für deine relative Einstufung und für das Preisniveau als Eingang.

## Wind-Faktor 2,8: dein Befund stimmt, und ich kann ihn erklären

Meine Gewichte sind tatsächlich küstenlastig:

| Knoten | Solar | Wind |

|---|---|---|

| Nord/Küste (53,9 / 8,1) | 0,10 | 0,32 |

| Ostsee (54,3 / 13,1) | 0,05 | 0,16 |

| Hannover (52,4 / 9,7) | 0,15 | 0,20 |

| NRW (51,4 / 7,0) | 0,15 | 0,14 |

| Frankfurt (50,1 / 8,7) | 0,20 | 0,10 |

| München (48,1 / 11,6) | 0,35 | 0,08 |

Das erklärt aber nur einen Teil. Der eigentliche Fehler: Den Wind-Flottenfaktor 0,44 habe ich aus der gemessenen Spitze eines 30-Tage-Fensters im Sommer abgeleitet (damals 35,6 GW von 81,5 GW installiert). Im Fenster 13.10.–12.11. liegt die gemessene Spitze bei 53,6 GW, das wären 0,66. Der Faktor war also ein Sommerwert, und dass ein Faktor aus der Spitze auch das Mittel drückt, kommt wie von dir beschrieben dazu.

Aufgefangen wird das allein durch die Kalibrierung gegen `ren_share_forecast`: Im August lag mein Kalibrierfaktor bei 0,97, heute bei 1,39. Er hebt Wind und Solar also inzwischen um fast 40 % an und repariert damit still einen falschen Modellparameter. Ohne den Anker wäre ich genau bei deinem Nachbau gelandet.

Ganz fängt er es nicht auf. Gegen die gemessene Residuallast liegt mein Modell im Live-Protokoll bei jedem Vorlauf 6–7 GW zu niedrig (MAE 6,2 GW bei Vorlauf 0, 8,0 GW bei Vorlauf 4), der Fehler ist fast vollständig Versatz. Deine 9,0 GW für den Nachbau und 5,5 GW für das gelernte Modell passen dazu. Auch der direkte Vergleich mit deinem JSON von heute zeigt denselben Versatz:

| Tag | DVhub Mittel / Spitze | mein Detektor Mittel / Spitze |

|---|---|---|

| 14.11. | 29,4 / 44,4 GW | 21,4 / 34,1 GW |

| 15.11. | 14,5 / 22,9 | 9,6 / 21,1 |

| 16.11. | 20,0 / 33,1 | 7,2 / 21,1 |

| 17.11. | 30,1 / 41,5 | 22,7 / 37,5 |

In der Aussage sind wir uns einig: kein teurer Tag in Sicht.

## Was ich daraus mitnehme

1. Auslöser auf Tagesmittel und relative Einstufung umstellen. Das war meine offene Frage 3, und du hast sie mit zwei Jahren Daten beantwortet. Das Ensemble behalte ich für die Unsicherheitsangabe.

2. Flottenfaktoren nicht mehr aus einer Spitze ableiten, sondern je Vorlauf aus den archivierten Prognosen lernen, so wie du es gemacht hast.

3. Lastmodell mit Temperatur und Feiertagen. Mein 30-Tage-Profil kennt beides nicht.

## Zum Hebel

Die Rechnung für reine Arbitrage glaube ich dir sofort. Wenn du den Fall „nicht verschiebbare Wärmepumpe, Speicher vor teuren Tagen vollhalten" rechnen willst, kann ich die Eckdaten liefern: 19,66 kWh Speicher, im Januar rund 36 kWh Netzbezug pro Tag bei unter 6 % Autarkie, im Juli praktisch null. Der Nutzen fällt also nur in etwa vier Monaten an, dort aber an jedem teuren Tag.

## Skript

Ja, gern, es liegt jetzt öffentlich unter MIT-Lizenz hier: GitHub - blockwatcher/residuallast-fruehwarnung · GitHub

Es sind sechs Python-Dateien ohne Fremdbibliotheken (Detektor mit Ensemble, Validierung, Rückblick, Güte nach Vorlauf und der Abgleich von oben). Das Protokoll mit den Prognosen seit August liegt als `validation-forecasts.jsonl` dabei, dann kannst du deinen Nachbau direkt gegen das Original halten. Die bekannten Schwächen stehen in der README.

Danke für den Verweis auf den Thread, und Glückwunsch zum Live-Gang. Ein eingefrorenes Modell, das ab jetzt an echten Preisen gemessen wird, ist die ehrlichste Prüfung.

Viele Grüße

Darius