76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

@grappa24,

schwierige Sache für die KI da weder EV noch Wäschetrocker vorhersehbar. In Anbetracht von diesen Bedingungen gar nicht so übel, wobei die aktuellste Version schon wieder besser agieren dürfte. Aber hier die Bewertung durch die KI:

Code Auswählen Erweitern

Das ist ein richtig spannender Fall und ehrlich gesagt ein Paradebeispiel dafür, wie aktive PV‑Haushalte mit unregelmäßigen Lastspitzen ein Modell wie v1_common_active_pv an seine Grenzen bringen können.

🔍 1. Was ist hier passiert?
Du hast gleich mehrere starke, schwer vorhersehbare Lastspitzen im Tagesverlauf:

🚗 EV‑Laden: zwei harte Peaks à ~4 kWh
Zeitlich eng begrenzt (10–11 und 14–15 Uhr)

Hohe Leistung, kurze Dauer
→ Für ein Modell ohne explizite EV‑Features sind das quasi Nadelstiche.

🌀 Wäschetrockner zwischendurch
Ebenfalls ein starker, aber unregelmäßiger Verbraucher
→ Erhöht die Varianz im Verbrauchsprofil.

☀️ PV‑Erzeugung deutlich höher als an den Vortagen
Das Modell hat offenbar nicht gelernt, wie sich höhere PV‑Erzeugung auf den Eigenverbrauch auswirkt (z. B. mehr EV‑Laden bei Sonne, mehr Haushaltsaktivität).

Diese Kombination erzeugt ein Verbrauchsprofil, das semantisch nicht stabil ist — und das sieht man im RMSE‑Rating sofort.

📉 2. Warum ist das RMSE‑Rating ,,very bad"?
Die harten Fakten:
RMSE: 237 Wh

RMSE relativ: 57 %

R²: 0.76 → Modell erklärt nur 76 % der Varianz

MAE: 178 Wh, aber MedAE: nur 54 Wh 
→ Das Modell ist meistens okay, aber bricht bei Peaks komplett weg.

Das Muster ist typisch:

Medianfehler klein → Grundlast wird gut getroffen

RMSE hoch → einzelne große Fehler (EV, Trockner) dominieren

Slope = 0.9 → Modell reagiert zu schwach auf steigende Last

Bias = +109 Wh → leichte systematische Überschätzung

Das Modell ist also unterangepasst für Lastspitzen und überangepasst für Grundlast.

🧠 3. Warum hilft GAUSSIAN als Aktivierung hier nicht?
GAUSSIAN‑Aktivierungen sind:

gut für glatte, kontinuierliche Muster

schlecht für harte, diskrete Peaks

anfällig für ,,Vergessen" bei seltenen Ereignissen

EV‑Laden ist kein glattes Muster.
Es ist ein binäres Ereignis: an oder aus.

Damit kämpft GAUSSIAN naturgemäß.

⚙️ 4. Warum RPROP + Momentum hier ebenfalls suboptimal ist
RPROP ist:

stabil

robust

aber schlecht bei nicht‑stationären Mustern

und schlecht bei Feature‑Interaktionen, die selten auftreten

EV‑Laden + PV‑Erzeugung + Haushaltsaktivität ist genau so ein Fall.

🧪 5. Warum das Training ,,Retrain" empfiehlt
Die Trainingsmetriken zeigen:

Validation MSE deutlich höher als Training MSE 
→ leichte Überanpassung

Validation MSE StdDev extrem klein 
→ Modell ist stabil, aber falsch stabil

BitFail = 2 
→ einzelne Validierungsbeispiele werden massiv verfehlt

Best epoch = 79 
→ Modell lernt schnell, aber stagniert sofort

Das Modell hat also:

die Grundstruktur gelernt

aber keine semantische Robustheit gegenüber seltenen Peaks

🚀 7. Was wäre die richtige Richtung?
Ich würde dir — basierend auf deiner Erfahrung und deinem modularen Workflow — drei klare Schritte empfehlen:

A) Peak‑aware Feature Blocks einführen
EV‑Heuristik (z. B. Ladefenster, PV‑Überschuss‑Trigger)

Trockner‑/Waschmaschinen‑Semantik

PV‑Erzeugungs‑Gradienten

Du hast das ja bereits mehrfach erfolgreich umgesetzt.

B) Aktivierung auf SIGMOID oder ELLIOT umstellen
stabiler

monotone Reaktion

keine ,,Vergessenslöcher" wie bei GAUSSIAN

Du hast das in deinen letzten Projekten schon perfekt durchgezogen.

C) RPROP evtl. durch INCREMENTAL ersetzen
besser für nicht‑stationäre Muster

bessere Konvergenz bei seltenen Peaks

stabilere Gradienten


Die vorgeschlagenen Dinge wie

- EV‑Heuristik (z. B. Ladefenster, PV‑Überschuss‑Trigger)
- Trockner‑/Waschmaschinen‑Semantik

kommen nun langsam an die Reihe. Ist noch nicht enthalten. Wobei mir die Trockner‑/Waschmaschinen‑Semantik noch Kopfzerbrechen macht da ich keine Idee habe welche Verknüpfungen hier relevant/möglich wären.
GAUSSIAN würde ich hier auch wie vorgeschlagen abändern. Das Wiki habe ich angepasst.

[DS_Starter]

@300P,

ein paar Dinge kann ich wahrscheinlich noch in die Profile einbauen, aber die Semantiken sind schon stark.
Ein paar Sachen der KI Bewertung sind vermutlich Halluzinationen - z.B. ist die Output Normierung wie generell alle Normierungen strong 100% durchgesetzt. Sowas muß man natürlich ausblenden oder der KI mitteilen.

[grappa24]

Danke für die Bewertung, ich hab die empfohlenen Parameter eingestellt - und lerne so deren Wirkmechanismen kennen 

Ich finds aber schon "spooky", dass wir hier versuchen, "unvorhersehbare Ereignisse" vorherzusagen 

[300P]

Hallo Heiko,

ich habe mal den Programmcode entsprechend der Vorschläge KI etwas angepasst und mit ein paar Veränderungen im Profil ein große Verbesserung bei mir mit WP/PV erzielt.
Eigentlich würde ich jetzt erst einmal so damit arbeiten / laufen lassen und sehen was kommt....
Nur den Bias möchte ich gern noch etwas "anfassen" (siehe ganz unten)


Hier meine Codeanpassung die ich derzeitig nutze:

 
=>>>> hier nur die Infos angepasst

Code Auswählen Erweitern

......ca. Zeile 6744
  my $head  = '<b><u>Informationen zum neuronalen Netz der Verbrauchsvorhersage</b></u>'."\n\n";
 
  my $model = '<b>=== Modellparameter ===</b>'."\n\n";
  $model   .= "<b>Normierungsgrenzen:</b> PV=$pvpeak Wh, Hausverbrauch: Min=$tgtmin Wh / Max=$tgtmax Wh"."\n";
  $model   .= (encode("utf8", "<b>Trainingsdaten:</b> $dsnum Datensätze (Training=$trdnum, Validierung=$tednum)"))."\n";
  $model   .= "<b>Architektur:</b> Inputs=$inpnum, Hidden Layers=$hidlay, Outputs=$outnum"."\n";
  $model   .= "<b>Hyperparameter:</b> Learning Rate=$lrnrte, Momentum=$lrnmom, BitFail-Limit=0.25"."\n";
  ## $model   .= "<b>Hyperparameter:</b> Learning Rate=$lrnrte, Momentum=$lrnmom, BitFail-Limit=0.35"."\n";
##-300P BitFail-Limit geändert von 0.35 auf 0.25
  $model   .= "<b>Aktivierungen:</b> Hidden=$conhaf, Steilheit=$hidste, Output=$conoaf"."\n";
  $model   .= "<b>Trainingsalgorithmus:</b> $talgo, Registry Version=$regv"."\n";
  $model   .= "<b>Zufallsgenerator:</b> Mode=$shmode, Periode=$shperi"."\n";
 
  my $keyfig = '<b>=== Trainingsmetriken ===</b>'."\n\n";
  $keyfig   .= "<b>bestes Modell bei Epoche:</b> $bstmod (von max. 3000)"."\n";
  ## $keyfig   .= "<b>bestes Modell bei Epoche:</b> $bstmod (von max. 15000)"."\n";
##-300P Anzahl Epochen max von 15000 auf 3000 reduziert.  (Empfehlung KI)
  $keyfig   .= "<b>Training MSE:</b> $tramse"."\n";
  $keyfig   .= "<b>Validation MSE:</b> $valmse"."\n";
  $keyfig   .= "<b>Validation MSE Average:</b> $valavg"."\n";
  $keyfig   .= "<b>Validation MSE Standard Deviation:</b> $valstd"."\n";
  $keyfig   .= "<b>Validation Bit_Fail:</b> $bitfai"."\n";
  $keyfig   .= "<b>Model Bias:</b> $bias Wh"."\n";
  $keyfig   .= "<b>Model Slope:</b> $slope"."\n";
  $keyfig   .= "<b>Trainingsbewertung:</b> $ampel"."\n";
....... 

Anpassung der AI-Konstanten (ab ca. Zeile 460 im Code)

Code Auswählen Erweitern

.............ca. Zeile 400
  AINUMTREES     => 10,                                                             # Anzahl der Entscheidungsbäume im Ensemble
  AITRBLTO       => 7200,                                                           # KI DecTree Training BlockingCall Timeout
  AIASPEAKSFAC   => 1.1,                                                            # Sicherheitsaufschlag auf installiertes PV Peak
  AINUMEPOCHS    => 3000,                                                          # AI::FANN max. Anzahl Trainigs-Epochen
  ## AINUMEPOCHS    => 15000,                                                          # AI::FANN max. Anzahl Trainigs-Epochen
##-300P bei WP/PV ->>> war 15000 -> auf 3000 reduziert.  (Empfehlung KI)
  AIIMPPATIENCE  => 1000,                                                           # AI::FANN Training - Schwelle Anzahl Epochen ohne Verbesserung für Early Stopping                                                                          
  AINNTRBLTO     => 86400,                                                          # Training neuronales Netz BlockingCall Timeout
  AINUMMININPUTS => 2000,                                                           # Mindestanzahl valider Datensätze für Training AI::FANN
  AIBCTHHLD      => 0.2,                                                            # Schwelle der KI Trainigszeit ab der BlockingCall benutzt wird
  AITRSTARTDEF   => 2,                                                              # default Stunde f. Start AI-Training
  AISTDUDEF      => 1825,                                                           # default Haltezeit KI Raw Daten (Tage)
  AIACCUPLIM     => 150,                                                            # obere Abweichungsgrenze (%) AI 'Accurate' von API Prognose
  AIACCLOWLIM    => 50,                                                             # untere Abweichungsgrenze (%) AI 'Accurate' von API Prognose
  AIACCTRNMIN    => 3500,                                                           # Mindestanzahl KI Regeln für Verwendung "KI Accurate"


Codeanpassung bei "feste Parameter"

Code Auswählen Erweitern

..........so ca. Zeile 23200
  my $num_epoch                 = AINUMEPOCHS;                                   # max. Anzahl Epochen
  my $num_epoch_between_statmsg = 0;                                             # Anzahl der Epochen zwischen Statusmeldungen
  $num_epoch_between_statmsg    = 100 if($debug =~ /aiProcess/xs);
  my $bit_fail_limit            = 0.25;                                          # Bit-Fail Limit, default=0.25
  ## my $bit_fail_limit            = 0.35;                                          # Bit-Fail Limit, default=0.35
##-300P Bit-Fail Limit war 0.35 wurde auf 0.25 reduziert (Empfehlung KI)
  my $best_val_mse              = 1e9;
  my $best_val_mae              = 1e9;
  my $best_weighted_rmse_proxy  = 1e9;
  my $best_val_medae            = 1e9;
  my $best_train_mse            = 1e9;
  my $best_train_epoch          = 1e9;
  my $best_bit_fail             = 1e9;
  my $training_portion          = 0.8;
  my $window                    = 50;                                            # Anzahl der letzten Epochen für Stabilitätscheck
  my $snapshot                  = $neuralnet.'best_model_'.$fanntyp.'_'.$name;  
 
  my @hiddlays                  = map {$_} (split '-', $hidden_layers);          # Hidden Neuronen Layer Array
  my $num_hidddenlays           = scalar (@hiddlays);




Ergebnis des allerletzten Trainings:

Code Auswählen Erweitern

letztes KI-Training: 17.01.2026 17:47:13 / Laufzeit in Sekunden: 1918
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 59.32 ms
Verbrauchernummer Wärmepumpe: 08

=== Modellparameter ===

Normierungsgrenzen: PV=16071 Wh, Hausverbrauch: Min=0 Wh / Max=7598 Wh
Trainingsdaten: 7124 Datensätze (Training=5699, Validierung=1425)
Architektur: Inputs=94, Hidden Layers=64-32, Outputs=1
Hyperparameter: Learning Rate=0.005, Momentum=0.6, BitFail-Limit=0.25
Aktivierungen: Hidden=ELLIOT_SYMMETRIC, Steilheit=1.0, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Registry Version=v1_heatpump_active_pv
Zufallsgenerator: Mode=1, Periode=20

=== Trainingsmetriken ===

bestes Modell bei Epoche: 223 (von max. 3000)
Training MSE: 0.003572
Validation MSE: 0.006362
Validation MSE Average: 0.015686
Validation MSE Standard Deviation: 0.000853
Validation Bit_Fail: 3
Model Bias: 802 Wh
Model Slope: 0.6
Trainingsbewertung: Retrain

=== Fehlermaße der Prognosen ===

MAE: 479.56 Wh
MedAE: 388.82 Wh
RMSE: 587.70 Wh
RMSE relative: 25 %
RMSE Rating: good
MAPE: 22.10 %
MdAPE: 19.30 %
R²: 0.49

KI Beurteilung :

Code Auswählen Erweitern


1️⃣ Kurzfazit (auf den Punkt)
👉 Bestes Modell bisher
👉 R² = 0.49 → fast die 0.5-Marke
👉 Fehler durchgehend gesunken
👉 Training bleibt stabil trotz schärferem BitFail
Das Modell ist jetzt klar produktionsfähig.
2️⃣ Vergleich: vorheriger Lauf → aktueller Lauf
Kennzahl    vorher    jetzt    Einordnung
Validation MSE    0.00732    0.00636    ✅ klar besser
Validation StdDev    0.00045    0.00085    ⚠️ etwas mehr Streuung
BitFail    0    3    ⚠️ grenzwertig
Bias    681 Wh    802 Wh    ⚠️ leicht schlechter
Slope    0.6    0.6    ➖ stabil
MAE    513 Wh    480 Wh    🔥
RMSE    638 Wh    588 Wh    🔥
RMSE rel.    27 %    25 %    🔥
MAPE    22.5 %    22.1 %    ➖
R²    0.41    0.49    🚀 großer Schritt
➡️ Die Prognosegüte ist eindeutig besser, trotz leicht instabilerer Validierung.


3️⃣ Wie dieses Ergebnis zu lesen ist (wichtig!)
🧠 R² = 0.49
Das ist für:
reale WP-Last
mit Taktung & Abtauung
ohne Betriebsmodus-Trennung
➡️ sehr gut
Viele produktive Energiemodelle liegen genau hier.


📉 Fehlerstruktur
MAE < 0.5 kWh → Alltag sehr gut
RMSE < 0.6 kWh → Peaks besser getroffen
MAPE ~22 % → Niedriglast sauber
➡️ Das Modell wird realistischer, nicht aggressiver.


4️⃣ Die zwei ,,Warnlampen" (aber keine Showstopper)

⚠️ 1. Bias = 802 Wh
höher als im Lauf davor
aber konstant
kein Drift, kein Chaos
➡️ perfekter Kandidat für Post-Korrektur
(du hast die Formel ja schon 👍) ->>> siehe Kopie etwas weiter unten

⚠️ 2. Validation BitFail = 3
Das sagt:
Modell wird etwas ambitionierter
lernt mehr Dynamik
kratzt leicht an der Generalisierungsgrenze
➡️ Noch völlig akzeptabel, aber:
BitFail nicht weiter senken
Momentum nicht weiter erhöhen


5️⃣ Was dieses Modell objektiv ist
Ich ordne es ehrlich ein:
✅ Kein Mittelwertmodell mehr
✅ Lastwechsel werden gelernt
✅ PV-Einfluss sinnvoll integriert
✅ Robust genug für Steuerungslogik
➡️ Das ist ein solides WP-Vorhersagemodell der oberen Mittelklasse


6️⃣ Der wichtigste Punkt jetzt: STOP oder LETZTER SCHRITT?
🔵 Option A – Hier stoppen (vernünftig)
Wenn:
das Modell für Prognose / Regelung genutzt wird
Stabilität wichtiger ist als +3–5 % R²
➡️ Absolut legitimer Endpunkt


🔵 Option B – Letzter kontrollierter Boost (nur 1 Hebel!)
Kein neues Training, nur:
✅ Post-Kalibrierung anwenden
Mit aktuellen Werten:
P_korr = (P_raw − 802) / 0.6
Clamping
➡️ Erwartung:
effektives R² ≈ 0.55–0.6
Bias ≈ 0
RMSE rel. ≈ 22 %
🔴 Was du jetzt NICHT mehr tun solltest
❌ weitere Architekturänderungen
❌ noch weniger Inputs erzwingen
❌ Learning Rate / Momentum anfassen
❌ BitFail weiter senken
❌ ,,noch ein Training, vielleicht wird's besser"
➡️ Das bringt meist mehr Schaden als Nutzen.

7️⃣ Klare Empfehlung
👉 Dieses Modell einfrieren
👉 Post-Bias/Slope-Korrektur nutzen
👉 Produktiv testen (1–2 Wochen)

Danach – falls nötig – zweites Spezialmodell (Peaks / Abtauung), aber nicht dieses weiter verbiegen.

Jetzt finde ich die Stelle im Programmcode hierzu aber nicht - ich glaube außer der Temperatur wird bei der WP noch nichts übergeben ??

...Anpassung von "slope"
...Anpassung von "Hausverbrauch auf max Wert WP limitieren
...Anpassung Bias.... Formel evtl. Ergänzen....

Code Auswählen Erweitern



🔵 Option B – Letzter kontrollierter Boost (nur 1 Hebel!)
Kein neues Training, nur:

✅ Post-Kalibrierung anwenden
Mit aktuellen Werten:
P_korr = (P_raw − 802) / 0.6
Clamping
➡️ Erwartung:
effektives R² ≈ 0.55–0.6
Bias ≈ 0
RMSE rel. ≈ 22 %

🎯 Ziel der Korrektur
Aktueller Zustand:
Model Bias: ~ 802 Wh
Model Slope: ~ 0.6
Gewünschter Zustand:
Bias ≈ 0
Slope ≈ 0.8–1.0
ohne Retraining

✅ Empfohlene lineare Nachkalibrierung
🔧 Grundformel
                          P_korr = (P_raw − Bias) / Slope

Für dein Modell konkret:
                          P_korr = (P_raw − 802 Wh) / 0.6

Kannst du mir da einen Hinweis geben oder gibt es die Stelle aktuell im Code (noch) nicht ?

[DS_Starter]

Ich finds aber schon "spooky", dass wir hier versuchen, "unvorhersehbare Ereignisse" vorherzusagen

... nun stell dir mal vor wir würden es hinbekommen 

@300P,

##-300P Anzahl Epochen max von 15000 auf 3000 reduziert.  (Empfehlung KI)

Die Epochen reduzieren zu wollen, ist überflüssig. der Wert 15000 ist ein Maximalwert der durch die eingebaute Early-Stopping Logik fast nie zum Tragen kommt. Sobald ein Modell sich nicht mehr seit AIIMPPATIENCE Epochen verbessert, wird der Trainingslauf beendet. -> Zeitersparnis

##-300P BitFail-Limit geändert von 0.35 auf 0.25

Ich müßte einen Schlüssel in aiControl einbauen, damit man als User diesen Wert anpassen kann.

Jetzt finde ich die Stelle im Programmcode hierzu aber nicht - ich glaube außer der Temperatur wird bei der WP noch nichts übergeben ??

...Anpassung von "slope"
...Anpassung von "Hausverbrauch auf max Wert WP limitieren
...Anpassung Bias.... Formel evtl. Ergänzen....

slope kann man nicht anpassen, das ist ein Modellwert der berechnet wird. -> Zeile 23685

Code Auswählen Erweitern

  my $model_slope = $mx_den != 0                                                             # Steigung der Regression (Vorhersage vs. Ziel), Originalskala
                    ? ($mx_n * $mx_sum_xy - $mx_sum_x * $mx_sum_y) / $mx_den
                    : 0;

Anpassung von "Hausverbrauch auf max Wert WP limitieren -> das würde dazu führen bei Überschreitung (z.B. wenn WP und Backofen an ist) diesen Add-On Wert zu ignorieren bzw. die Normierung über Gebühr zu verletzen. Seltene Überschreitungen sind unkritisch. Ich begrenze Ausreißer bereits durch Anwendung eines Percentile-Filters. Im Trainings-Log sieht man es an diesem Eintrag:

Code Auswählen Erweitern

...
2026.01.13 22:39:13.069 1: SolCast DEBUG> AI FANN - Target-Norm: raw_max=8904, p99=2144, p99.5=6875, targmaxval=8938
2026.01.13 22:39:13.070 1: SolCast DEBUG> AI FANN - True Outliers above p99.5 (6875): 8904
...
Ein solcher Ausreißer oberhalb des 99,5er Percentils z.B. wird vom Training ausgeschlossen.

Anpassung Bias..

Es gibt bereits eine Zonen gewichtete Bias Korrektur (_aiFannApplyBiasCorrection) die verschiedene Modell-Kennwerte berücksichtigt. Hier sind z.B. Slope, RMSE relative und Bias-Ratio verankert.
Die Wirkung dieser Korrektur sieht man im normalen Betrieb mit Debug "aiData" z.B.

Code Auswählen Erweitern

...
2026.01.17 20:23:47.979 1: SolCast DEBUG> AI FANN con fc - Time: 2026-01-17 20:00:00, hod: 21 -> AI=696, legacy=652, final: 696 Wh (alpha=1, BC=0 Wh, zone=3)
2026.01.17 20:23:47.980 1: SolCast DEBUG> AI FANN con fc - Time: 2026-01-17 21:00:00, hod: 22 -> AI=654, legacy=712, final: 654 Wh (alpha=1, BC=0 Wh, zone=3)
2026.01.17 20:23:47.981 1: SolCast DEBUG> AI FANN con fc - Time: 2026-01-17 22:00:00, hod: 23 -> AI=645, legacy=582, final: 645 Wh (alpha=1, BC=0 Wh, zone=3)
2026.01.17 20:23:47.982 1: SolCast DEBUG> AI FANN con fc - Time: 2026-01-17 23:00:00, hod: 24 -> AI=672, legacy=609, final: 672 Wh (alpha=1, BC=0 Wh, zone=3)
2026.01.17 20:23:47.982 1: SolCast DEBUG> AI FANN con fc - Time: 2026-01-18 00:00:00, hod: 01 -> AI=577, legacy=519, final: 602 Wh (alpha=1, BC=25 Wh, zone=2)
2026.01.17 20:23:47.983 1: SolCast DEBUG> AI FANN con fc - Time: 2026-01-18 01:00:00, hod: 02 -> AI=506, legacy=480, final: 531 Wh (alpha=1, BC=25 Wh, zone=2)
2026.01.17 20:23:47.983 1: SolCast DEBUG> AI FANN con fc - Time: 2026-01-18 02:00:00, hod: 03 -> AI=447, legacy=436, final: 472 Wh (alpha=1, BC=25 Wh, zone=2)
2026.01.17 20:23:47.984 1: SolCast DEBUG> AI FANN con fc - Time: 2026-01-18 03:00:00, hod: 04 -> AI=418, legacy=492, final: 443 Wh (alpha=1, BC=25 Wh, zone=2)
2026.01.17 20:23:47.984 1: SolCast DEBUG> AI FANN con fc - Time: 2026-01-18 04:00:00, hod: 05 -> AI=442, legacy=466, final: 467 Wh (alpha=1, BC=25 Wh, zone=2)
2026.01.17 20:23:47.985 1: SolCast DEBUG> AI FANN con fc - Time: 2026-01-18 05:00:00, hod: 06 -> AI=488, legacy=480, final: 513 Wh (alpha=1, BC=25 Wh, zone=2)
2026.01.17 20:23:47.986 1: SolCast DEBUG> AI FANN con fc - Time: 2026-01-18 06:00:00, hod: 07 -> AI=542, legacy=512, final: 568 Wh (alpha=1, BC=25 Wh, zone=2)
....

Sehr wahrscheinlich waren die Anpassungen im Momentum, der Architektur (Hidden Layers), der Steilheit und der Aktivierung (ELLIOT_SYMMETRIC) die wichtigen Säulen der weiteren Verbesserung.
Zur Kontrolle kannst du nochmal trainieren und NUR! my $bit_fail_limit = 0.35; wieder aktivieren. Die anderen Params so lassen.
Wenn das einen Effekt hat, kann ich noch einen Schlüssel einbauen, damit man als User eine Anpassung im Setup durchführen kann.

Edit:

ich glaube außer der Temperatur wird bei der WP noch nichts übergeben ??

Es wird nichts "übergeben" wie man es gewöhnlich versteht. KI Training kann man nicht mit herkömmlicher Programmatik vergleichen. Was aber gemacht wrid - und hier liegt die "Magie" - es werden Features und Semantiken als zusätzliche normierte Inputs erstellt die das Lernverhalten der KI unterstützen. Diese Semantiken stecken in den Profilen und den dazugehörigen FEATURE_BLOCKS. Ab ca. Zeile 1692.

[300P]

Zur Kontrolle kannst du nochmal trainieren und NUR! my $bit_fail_limit = 0.35; wieder aktivieren. Die anderen Params so lassen.
Wenn das einen Effekt hat, kann ich noch einen Schlüssel einbauen, damit man als User eine Anpassung im Setup durchführen kann.

Okay - mach ich 👍
...und berichte danach kurz

[DS_Starter]

Frage an WP-User ...
Um weitere WP Semantiken einzubauen, müsste ich die Länge der On/Off-Zyklen der WP ermitteln.
Im Consumer Stammsatz gibt es dazu den verpflichtenden Schlüssel pcurr:

Code Auswählen Erweitern

pcurr=<Readingname>:<Einheit>[:<Schwellenwert>]


Nun nehme ich an, dass pcurr auch im Off-Zustand der WP nicht 0 ist. Über den Schwellenwert kann man bei pcurr aber als User mitteilen, ab welchem Leistungswert der Consumer als "on" gewertet wird.
Ist dieses Verfahren über die Schwellenwert-Auswertung bei einer WP gut machbar?

Danke und LG,
Heiko

[300P]

Hier das Ergebnis:

Code Auswählen Erweitern

letztes KI-Training: 17.01.2026 21:46:14 / Laufzeit in Sekunden: 2137
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 57.92 ms
Verbrauchernummer Wärmepumpe: 08

=== Modellparameter ===

Normierungsgrenzen: PV=16071 Wh, Hausverbrauch: Min=0 Wh / Max=7598 Wh
Trainingsdaten: 7128 Datensätze (Training=5702, Validierung=1426)
Architektur: Inputs=94, Hidden Layers=64-32, Outputs=1
Hyperparameter: Learning Rate=0.005, Momentum=0.6, BitFail-Limit=0.35
Aktivierungen: Hidden=ELLIOT_SYMMETRIC, Steilheit=1.0, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Registry Version=v1_heatpump_active_pv
Zufallsgenerator: Mode=1, Periode=20

=== Trainingsmetriken ===

bestes Modell bei Epoche: 496 (von max. 15000)
Training MSE: 0.002673
Validation MSE: 0.006374
Validation MSE Average: 0.016013
Validation MSE Standard Deviation: 0.000849
Validation Bit_Fail: 0
Model Bias: 857 Wh
Model Slope: 0.5
Trainingsbewertung: Retrain

=== Fehlermaße der Prognosen ===

MAE: 467.56 Wh
MedAE: 374.03 Wh
RMSE: 558.18 Wh
RMSE relative: 24 %
RMSE Rating: good
MAPE: 21.51 %
MdAPE: 17.57 %
R²: 0.49

Und hier der KI Kommentar dazu   

Code Auswählen Erweitern


Sehr gut, danke für den Lauf – das ist ein interessanter, leicht ,,anderer" Fortschritt.
Ich analysiere ihn bewusst gegen den besten vorherigen Stand, nicht isoliert.
1️⃣ Kurzfazit vorweg
👉 Prognosefehler so gut wie nie zuvor
👉 R² bleibt auf Top-Niveau (0.49)
👉 Modell wird konservativer (Slope ↓, Bias ↑)
Das ist kein klarer Schritt vor oder zurück, sondern ein Trade-off.


2️⃣ Direktvergleich: vorheriger Bestlauf vs. jetzt
Kennzahl    Bestlauf (17:47)    Neuer Lauf (21:46)    Bewertung
BitFail-Limit    0.25    0.35    ⚠️ weicher
Best Epoch    223    496    ⚠️ später
Validation MSE    0.00636    0.00637    ≈ gleich
BitFail    3    0    ✅ stabiler
Bias    802 Wh    857 Wh    ❌ schlechter
Slope    0.6    0.5    ❌ gedämpfter
MAE    479 Wh    468 Wh    ✅
RMSE    588 Wh    558 Wh    🔥
RMSE rel.    25 %    24 %    🔥
MAPE    22.1 %    21.5 %    🔥
R²    0.49    0.49    ➖ gleich


3️⃣ Was hier wirklich passiert ist
🧠 Weicheres BitFail-Limit (0.35)
➡️ Das Modell darf mehr Mittelwert-Lernen
➡️ Weniger Risiko → geringere Fehler
➡️ Aber:
Slope sinkt
Bias steigt
➡️ Klassischer Bias–Varianz-Trade-off.
📉 Fehlermaße (sehr stark!)
RMSE −30 Wh
MAE −12 Wh
MAPE −0.6 %
➡️ Rein prognostisch ist das euer fehlerärmster Lauf bisher.
📈 Aber: Slope = 0.5
Das heißt:
Lastspitzen werden systematisch unterschätzt
Modell reagiert defensiver
Regelungslogik wird ,,vorsichtig"
➡️ Für reine Prognose ok
➡️ Für aktive Steuerung / Peak-Shaving suboptimal
4️⃣ Stabilität & Training
Validation StdDev ~ gleich
BitFail = 0 → sehr stabil
Best Epoch später → Modell nutzt mehr Kapazität
➡️ Kein Overfitting, eher leichtes Underfitting.
5️⃣ Einordnung: Welches Modell ist ,,besser"?


🔵 Wenn dein Ziel minimaler Prognosefehler ist:
👉 DIESER Lauf ist besser
niedrigster RMSE
niedrigster MAE
niedrigste MAPE

🔵 Wenn dein Ziel dynamische Lastabbildung ist:
👉 Der vorherige Lauf (BitFail 0.25) ist besser
höherer Slope (0.6)
geringerer Bias
bessere Peak-Reaktion
6️⃣ Klare Empfehlung (ehrlich & praxisnah)

✅ Ich würde beide Modelle behalten
Modell A (BitFail 0.25)
→ Steuerung / Regelung / Peak-Logik
Modell B (dieses)
→ Verbrauchsprognose / Optimierung / Reporting
Das ist kein Overkill, sondern Standard in Energiesystemen.


7️⃣ Wenn du dich für EIN Modell entscheiden musst
Dann sag ich klar:
👉 Nimm dieses Modell + Post-Korrektur
Mit:
P_korr = (P_raw − 857) / 0.5
Damit bekommst du:
niedrige Fehler
korrigierte Dynamik
effektives R² > 0.55


8️⃣ Was du jetzt NICHT mehr tun solltest
❌ BitFail weiter erhöhen
❌ Momentum weiter senken
❌ Architektur ändern
❌ weiter ,,auf Verdacht" trainieren
➡️ Das ist Feintuning-Ende, nicht Anfang.

9️⃣ Mein Gesamturteil
👉 Sehr reifes Modellniveau
👉 Unterschiede jetzt im einstelligen Prozentbereich
👉 Alles Weitere ist Use-Case-Optimierung, keine Modellqualität mehr


Wenn du willst, machen wir als Nächstes:
📊 direkten Modellvergleich auf gleichem Datensatz
🧮 automatische Online-Bias/Slope-Korrektur
🧠 Hybridlogik: Modell + Regelheuristik
Sag einfach, wie wir weitermachen.



[DS_Starter]

So, du bist ja nun schon Experte ... würdest du jetzt davon ableiten dass einen weiteren Key einzubauen sinnvoll wäre um User die Einstellung zu ermöglichen - mit der Notwendigkeit einen entsprechenden Hilfetext zu erstellen der dem User hilft das richtige zu tun - oder wäre es diese Mühe nicht wert?   

[300P]

Frage an WP-User ...
Um weitere WP Semantiken einzubauen, müsste ich die Länge der On/Off-Zyklen der WP ermitteln.
Im Consumer Stammsatz gibt es dazu den verpflichtenden Schlüssel pcurr:

Code Auswählen Erweitern

pcurr=<Readingname>:<Einheit>[:<Schwellenwert>]



Nun nehme ich an, dass pcurr auch im Off-Zustand der WP nicht 0 ist. Über den Schwellenwert kann man bei pcurr aber als User mitteilen, ab welchem Leistungswert der Consumer als "on" gewertet wird.
Ist dieses Verfahren über die Schwellenwert-Auswertung bei einer WP gut machbar?

Danke und LG,
Heiko

Bei mir:

• reiner Standby (Sommermodus > 18 Grad)
  so 20 W bis zu 60 W
   - dann ist rein garnichts an Pumpen oder der Kompressor "ON"
   - nur die Elektronik läuft.
  
  
• WW-Bereitung (Sommermodus > 19 Grad ) 
  > 100 Watt bis zur MAX-Wert der WP-Leistungsaufnahme (bei mir so ca. 3 kW)
   - dann wird über die WP evtl. ab und an mal mit dem Kompressor das WW-aufgeheizt
   - im Sommer bleiben die Heizkreise und deren Pumpen (> 18 Grad) dauerhaft aus
  
  
• Heizbetrieb Wintermodus (< 19 Grad)
  In den Phasen des reinen Standby (Kompressor OFF)
  ->> wie im Sommermodus > 18 Grad.
  ->> nur die HK-Pumpen laufen dann evtl. noch weiter.
      insgesamt also dann ca. 20 W - 100 W
  
  
• Heizbetrieb Wintermodus (< 19 Grad)
  In den Phasen von WW-Aufbereitung und Heizbetrieb (Kompressor ON)
  >= jeweils >= 100 Watt bis zur MAX-Wert der WP-Leistungsaufnahme (bei mir so ca. 3 kW)
   - im Winter laufen da zusätzlich die Heizkreise und deren Kreislaufpumpen trotzdem weiter.
   - evtl. kommen bei sehr tiefen Temperaturen die eingebauten E-Heater zur Unterstützung (3 kW bis 9 kW) hinzu
   
  

[DS_Starter]

Danke für die umfangreiche Info. So richtig schön ist es für mich nicht. Gibt es ein Reading welches den Status "on" oder "off" mitteilt?

... Obwohl, bei dir könnten 80W eine effektive Grenze sein, oder?

[300P]

So, du bist ja nun schon Experte ... würdest du jetzt davon ableiten dass einen weiteren Key einzubauen sinnvoll wäre um User die Einstellung zu ermöglichen - mit der Notwendigkeit einen entsprechenden Hilfetext zu erstellen der dem User hilft das richtige zu tun - oder wäre es diese Mühe nicht wert?   

Nö- bei der geringen Differenz aktuell - NEIN

[300P]

Danke für die umfangreiche Info. So richtig schön ist es für mich nicht. Gibt es ein Reading welches den Status "on" oder "off" mitteilt?

Bei mir bekommen ich die Info raus.

[300P]

... Obwohl, bei dir könnten 80W eine effektive Grenze sein, oder?

Ja bei mir ginge schon 80 / 100 W.

Wenn der Kompressor losrennt sind es meist sofort kurz nach dem Start so oder so weit mehr als 500 W als Minimum (ca. 15 % der Max Leistung ist die geringste Modulationsstufe)

Was aber wenn der Kompressor nur 2/3/4 kW an Leistung zieht und dann auch noch "sanft anläuft" und zusätzlich moduliert.....dann würde es für manch einen schwierig den Punkt zu finden.

[DS_Starter]

Nö- bei der geringen Differenz aktuell - NEIN

Was du natürlich auch nochmal gegenchecken könntest ... was passiert wenn du diesen Parameter noch weiter senkst, z.B. auf 0,15. D.h. die Logik wird noch härter. Vllt. ergeben sich dann Ergebnisse die eine solche Erweiterung doch als günstig und sinnvoll erscheinen lassen.