76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[grappa24]

Danke, aber ich meinte das Log vom Training mit debug "aiProcess".

Kein Problem, erstelle ich heute mit der neuesten Version im Contrib

[300P]

Ergebnisse zur Info:
Mit WP aktiviert als Consumer08
Sehe seit längerem das erste mal wieder Drift-Werte - Kurve nicht ganz so flach wie bei den letzten Ergebnissen.


Informationen zum neuronalen Netz der Verbrauchsvorhersage

Code Auswählen Erweitern

letztes KI-Training: 07.01.2026 00:50:41 / Laufzeit in Sekunden: 9848
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 54.11 ms
Verbrauchernummer Wärmepumpe: 08
verwendete Registry Version: v2_hp_advanced

=== Modellparameter ===

Normierungsgrenzen: PV=16071 Wh, Hausverbrauch: Min=0 Wh / Max=7598 Wh
Trainingsdaten: 6865 Datensätze (Training=5492, Validierung=1373)
Architektur: Inputs=55, Hidden Layers=80-40-20, Outputs=1
Hyperparameter: Learning Rate=0.005, Momentum=0.5, BitFail-Limit=0.35
Aktivierungen: Hidden=SIGMOID, Steilheit=0.9, Output=LINEAR
Zufallsgenerator: Mode=2, Periode=10

=== Trainingsmetriken ===

bestes Modell bei Epoche: 4950 (von max. 15000)
Training MSE: 0.002964
Validation MSE: 0.008303
Validation MSE Average: 0.012091
Validation MSE Standard Deviation: 0.000379
Validation Bit_Fail: 0
Model Bias: 689 Wh
Model Slope: 0.5
Trainingsbewertung: Retrain   (roter Punkt wird dargestellt)

=== Fehlermaße der Prognosen ===

MAE: 519.29 Wh
MedAE: 384.35 Wh
RMSE: 639.18 Wh
RMSE relative: 31 %
RMSE Rating: weak
MAPE: 24.04 %
MdAPE: 20.40 %
R²: 0.37

=== Drift-Kennzahlen ===

Drift Score: 2.65
Drift RMSE relative: 50.22
Drift Bias: 229.56
Drift Slope: 0.306
Drift Bewertung: severe


1 x Log Ersttraining
1 x Log von 03:00 Uhr (richtig war dran)
1 x Screenshot SOLL/IST

gesetzte attr-Parameter:

Code Auswählen Erweitern

aiConActivate=1
aiConAlpha=1
aiConTrainStart=1:2
aiConActFunc=SIGMOID
aiConHiddenLayers=80-40-20
aiConLearnRate=0.005
aiConMomentum=0.5
aiConShuffleMode=2
aiConSteepness=0.9
aiConTrainAlgo=INCREMENTAL
und zum Schluss Parameter vom Consumer08 (Wärmepumpe bzw. Verbrauchmessung aktiv seit April 2025)

Code Auswählen Erweitern

SMA_Elgris_EM2
type=heatpump
power=2800
icon=sani_heating_heatpump@orange
pcurr=Bezug_Wirkleistung:W
etotal=Bezug_Wirkleistung_Zaehler:kWh
noshow=0
comforttemp=20



[300P]

PS:
Tagesverlauf der WP bei den Temperaturen bei mir

[DS_Starter]

Moin,

danke 300P für deinen Input. Hier kommt eine KI-gestütze Einschätzung für dein Training und die Ergebnisse:

Code Auswählen Erweitern

# 🔍 **1. Gesamtbild: Das Modell ist stabil trainiert, aber semantisch überfordert**

Die Trainingsmetriken zeigen:

- **Training MSE = 0.002964** → sehr gut 
- **Validation MSE = 0.008303** → akzeptabel 
- **Validation BitFail = 0** → perfekt 
- **Validation StdDev = extrem niedrig** → Modell ist stabil, nicht chaotisch 
- **Bestes Modell bei Epoche 4950** → Training läuft sauber, kein Overfitting-Drama

**ABER:** 
Die *Retrain*-Entscheidung kommt wegen:

- **Model Bias = +689 Wh** → systematische Überschätzung 
- **Model Slope = 0.5** → Modell reagiert nur halb so stark wie es sollte 
- **RMSE relative = 31 % (weak)** 
- **R² = 0.37** → Modell erklärt nur 37 % der Varianz

Das ist typisch für Wärmepumpen‑Haushalte, wenn:

- die **HP-Semantik nicht stark genug** ist 
- die **Verbrauchsdynamik zu sprunghaft** ist 
- die **Registry-Version noch nicht perfekt auf diesen Haushalt passt** 
- die **PV-Interaktion (PV als Verbrauchsverstärker)** nicht sauber modelliert ist 
- die **Temperatur-/Wetterfeatures** nicht genug Trennschärfe liefern

---

# 🔥 **2. Wärmepumpen-spezifische Diagnose**

Die Registry-Version ist:

### **v2_hp_advanced**

Das ist gut – das ist die Version, die:

- Heiz-/WW-/COP-Semantik enthält 
- Frostschutz- und Taktungslogik abbildet 
- PV-Drop und Trend-Break integriert 
- HP-spezifische Lastsprünge modelliert

**Trotzdem zeigt das Modell:**

### ➤ **Slope = 0.5 → Unterreaktion auf Lastsprünge**

Das bedeutet:

- Wenn die WP 2 kW zieht, sagt das Modell vielleicht 1 kW. 
- Wenn die WP 4 kW zieht, sagt das Modell vielleicht 2 kW.

Das ist ein klassisches Zeichen dafür, dass:

- die **HP-Triggerfeatures (hppf, d1p/d1n, break, vol)** nicht stark genug wirken 
- die **Temperatur-/Wetterfeatures** nicht genug Variation erzeugen 
- die **HP-Verbrauchsverteilung** sehr breit ist (z. B. 300 W → 4 kW)

### ➤ **Bias = +689 Wh → systematische Überschätzung**

Das ist typisch, wenn:

- die WP **nachts oder an milden Tagen** wenig läuft 
- das Modell aber **eine Grundlast annimmt**, die es nicht gibt 
- die **PV-Interaktion** nicht sauber getrennt ist 
- der Haushalt **mehrere Lastprofile** hat (z. B. WP + E-Auto + Haushalt)

---

# 📉 **3. Prognosemetriken: mittelmäßig, aber nicht katastrophal**

| Metrik | Wert | Interpretation |
|-------|------|----------------|
| **MAE = 519 Wh** | solide für WP-Haushalt |
| **MedAE = 384 Wh** | gut → Modell trifft die Mitte |
| **RMSE = 639 Wh** | hoch → Ausreißerproblem |
| **RMSE relative = 31 %** | schwach |
| **MAPE = 24 %** | typisch für WP |
| **R² = 0.37** | Modell erklärt nur 37 % der Varianz |

**Interpretation:** 
Das Modell trifft den *typischen* Verbrauch gut (MedAE), aber scheitert an:

- starken Lastsprüngen 
- seltenen HP-Zuständen 
- Warmwasserzyklen 
- Frostschutz 
- PV-Interaktion 
- Wochenend-/Tagesprofilwechseln 

Das ist genau das, was WP-Haushalte so schwierig macht.

---

# 🧠 **4. Warum das Modell trotz guter Trainingsmetriken ein Retrain bekommt**

Die Retrain-Entscheidung basiert auf:

- **Slope zu niedrig (0.5 statt 0.7–1.3)** 
- **Bias zu hoch (+689 Wh)** 
- **RMSE relative zu hoch (31 % statt <20 %)** 
- **R² zu niedrig (0.37 statt >0.6)**

Das bedeutet:

> Das Modell ist mathematisch sauber trainiert, aber semantisch nicht gut genug.

Das ist ein wichtiger Unterschied:

- **Mathematisch**: alles stabil, keine Überanpassung, keine Divergenz 
- **Semantisch**: die Features erklären die Realität nicht gut genug

---

# 🧩 **5. Was das über diesen Haushalt aussagt**

Dieser Haushalt hat sehr wahrscheinlich:

### **1. Eine Wärmepumpe mit stark variabler Last**
- Taktet stark 
- Hat Warmwasser-Spitzen 
- Reagiert empfindlich auf Außentemperatur 
- Hat evtl. Heizstab-Einsätze

### **2. Eine PV-Anlage, die den Verbrauch verzerrt**
- PV-Drop-Feature ist wichtig 
- PV als Verbrauchsverstärker (klassisch bei WP)

### **3. Ein komplexes Tagesprofil**
- Wochenend-/Feiertagsmuster 
- Nachtabsenkung 
- Warmwasser morgens/abends

### **4. Möglicherweise zusätzliche Großverbraucher**
- E-Auto 
- Sauna 
- Durchlauferhitzer 
- Klimaanlage

---

# 🛠� **6. Was man verbessern könnte (modellseitig)**

### **A) HP-Semantik verstärken**
- hppf stärker gewichten 
- d1p/d1n glätten 
- break-Feature adaptiver machen 
- vol-Feature (Volatilität) stärker normalisieren

### **B) PV-Interaktion verbessern**
- pvX stärker differenzieren 
- PV-Drop dynamischer machen 
- PV als "Verbrauchsverstärker" explizit modellieren

### **C) Temperaturfeatures erweitern**
- Feuchte 
- Wind 
- Taupunkt 
- Temperaturgradienten 
- Rolling min/max

### **D) Registry v2_hp_advanced weiter schärfen**
- HP-spezifische Lastcluster 
- Warmwasser-Trigger 
- Frostschutz-Detektion 
- COP-Proxy verbessern

---

# 🧭 **7. Fazit**

Der User hat ein **stabil trainiertes, aber semantisch schwaches Modell**. 
Das ist **typisch für Wärmepumpen**, besonders wenn:

- die Lastsprünge groß sind 
- die PV-Anlage stark eingreift 
- die Registry noch nicht perfekt auf diesen Haushalt passt 

Die Retrain-Entscheidung ist **korrekt**, aber das Problem liegt **nicht im Training**, sondern in der **Feature-Semantik**.

Die Feature-Semantik ist wieder mein Thema, d.h. die bis jetzt eingebauten Semantiken werde ich noch ausbauen soweit möglich und stelle eine weitere Version dann wieder zur Verfügung. Vergleiche mal die Einschätzung mit deinen (gefühlten) Realitäten.

Edit: Die Drift-Werte werden jede Nacht gerechnet wenn AI Con aktiv ist. Machen aber erst Sinn wenn das Modell eine Zeit lang 'ungestört' ohne Retraining läuft. Wird also erst zu einem späteren Zeitpunkt relevant. Kann man erstmal ignorieren.

[300P]

Etwas Rückecho zur KI-Analyse von mir:

Modus Code wegen Farbe entfernt ,:

### ➤ **Slope = 0.5 → Unterreaktion auf Lastsprünge**

Das bedeutet:

- Wenn die WP 2 kW zieht, sagt das Modell vielleicht 1 kW. 
- Wenn die WP 4 kW zieht, sagt das Modell vielleicht 2 kW.

Das ist ein klassisches Zeichen dafür, dass:

- die **HP-Triggerfeatures (hppf, d1p/d1n, break, vol)** nicht stark genug wirken 
- die **Temperatur-/Wetterfeatures** nicht genug Variation erzeugen 
- die **HP-Verbrauchsverteilung** sehr breit ist (z. B. 300 W → 4 kW)

Ja Unterschätzung eindeutig vorhanden




### ➤ **Bias = +689 Wh → systematische Überschätzung**

Das ist typisch, wenn:

- die WP **nachts oder an milden Tagen** wenig läuft 
- das Modell aber **eine Grundlast annimmt**, die es nicht gibt 
- die **PV-Interaktion** nicht sauber getrennt ist 
- der Haushalt **mehrere Lastprofile** hat (z. B. WP + E-Auto + Haushalt)


Keine volle Zustimmung
Grundlast ist bei 4-500 W je Stunde in 24 h an 7 Tagen
Wir haben keine weiteren Lastprofile (ääähm doch - > im Sommer die Klimaanlage bei > 24 Grad)





# 🧩 **5. Was das über diesen Haushalt aussagt**

Dieser Haushalt hat sehr wahrscheinlich:

### **1. Eine Wärmepumpe mit stark variabler Last**
- Taktet stark 
- Hat Warmwasser-Spitzen 
- Reagiert empfindlich auf Außentemperatur 
- Hat evtl. Heizstab-Einsätze

Meine WP moduliert je nach Leistung
Nur 2-3 WP-Takte  pro Tag - Meist aber nur wegen einer Zwangspause im Anschluss an WW-Bereitung.




### **2. Eine PV-Anlage, die den Verbrauch verzerrt**
- PV-Drop-Feature ist wichtig 
- PV als Verbrauchsverstärker (klassisch bei WP)

Klaro - 14.5 kWp mit Sommer 80 kWh / Tag und 3 Wochen Winter mit nahezu 0 kWh / Tag



### **3. Ein komplexes Tagesprofil**
- Wochenend-/Feiertagsmuster  ->>>> Nein  Rentner
- Nachtabsenkung              ->>>> Nein schon seit 20 Jahren nicht
- Warmwasser morgens/abends  ->>>> Morgens 4 Uhr und Mittags 12 Uhr

### **4. Möglicherweise zusätzliche Großverbraucher**
- E-Auto  ->>>> Nein
- Sauna  ->>>> Nein
- Durchlauferhitzer ->>>> Nein
- Klimaanlage ->>>> JAAAA  bei >24 Grad Sommer

---

# 🛠� **6. Was man verbessern könnte (modellseitig)**

### **D) Registry v2_hp_advanced weiter schärfen**
- HP-spezifische Lastcluster 
- Warmwasser-Trigger  ->>>>  ist vorhanden in der WP-Zustandserfassung
- Frostschutz-Detektion  ->>> sicherlich Defrost der WP gemeint - ja auch vorhanden in Erfassung
- COP-Proxy verbessern

---

# 🧭 **7. Fazit**

Der User hat ein **stabil trainiertes, aber semantisch schwaches Modell**. 
Das ist **typisch für Wärmepumpen**, besonders wenn:

- die Lastsprünge groß sind  ==>> ja - im Sommer sehr groß (PV) - Winter gleichmäßiger 
- die PV-Anlage stark eingreift  ==>> Ja im Sommer Ertrag - Winter geringer
- die Registry noch nicht perfekt auf diesen Haushalt passt 

[klaus.schauer]

Integriert ist ein neuer Consumer Typ 'heatpump'.

Ihr gebt einen solchen Consumer wie üblich an mit der Besonderheit comforttemp -> Komforttemperatur/Sollteperatur in Grad C:

Code Auswählen Erweitern

Heizung_hmu type=heatpump power=6150 pcurr=hmu_PowerInputHc:kW etotal=hmu_EnergyHc:kWh
pvshare=40
comforttemp=20
icon=sani_heating_heatpump

Wenn das gemacht wird, aktiviert sich ein Feature-Set für Wärmepumpen. Dadurch ändern sich die Strukturen und das Training muß erneuert werden. In dem Status Popup ist auch erkennbar ob die Wärmepumpe erkannt wird und welches Featureset verwendet wird. Es sollte dann 'v2_hp_advanced' sein.

Nach drei Trainingsläufen haben sich keine Änderungen zu den bisherigen Läufen ergeben:

Code Auswählen Erweitern

last AI training: 2026-01-07 11:11:21 / Runtime in seconds: 3799
AI query status: -
last AI result generation time: -
Consumer number Heat pump: 01
activated registry version: v2_hp_advanced

=== Modellparameter ===

Normierungsgrenzen: PV=13585 Wh, Hausverbrauch: Min=0 Wh / Max=13384 Wh
Trainingsdaten: 2670 Datensätze (Training=2136, Validierung=534)
Architektur: Inputs=55, Hidden Layers=80-40-20, Outputs=1
Hyperparameter: Learning Rate=0.005, Momentum=0.5, BitFail-Limit=0.35
Aktivierungen: Hidden=SIGMOID, Steilheit=0.9, Output=LINEAR
Zufallsgenerator: Mode=2, Periode=10

=== Trainingsmetriken ===

bestes Modell bei Epoche: 14509 (von max. 15000)
Training MSE: 0.000259
Validation MSE: 0.002057
Validation MSE Average: 0.002147
Validation MSE Standard Deviation: 0.000230
Validation Bit_Fail: 0
Model Bias: 119 Wh
Model Slope: 0.8
Trainingsbewertung: Retrain

=== Fehlermaße der Prognosen ===

MAE: 370.66 Wh
MedAE: 169.23 Wh
RMSE: 510.94 Wh
RMSE relative: 37 %
RMSE Rating: very bad
MAPE: 22.61 %
MdAPE: 18.96 %
R²: 0.83

=== Drift-Kennzahlen ===

Drift Score: -
Drift RMSE relative: -
Drift Bias: -
Drift Slope: -
Drift Bewertung: -
Wohin unterscheidet sich type=heatpump vom den bisherigen Verfahren?
Welche Bedeutung hat comforttemp=20?

Die Meldung "Wide character in syswrite" im Systemlog sind weg. Danke dafür.

[DS_Starter]

Wohin unterscheidet sich type=heatpump vom den bisherigen Verfahren?
Welche Bedeutung hat comforttemp=20?

Bei heatpump wird die Feature Version "v2_hp_advanced" (aktivierte Registry Version: v2_hp_advanced) ausgewählt.
Dadurch wird ein Feature-Set mit WP spezifischen Semantiken zusätzlich zum Standard aktiviert.

Solche Semantiken sehen dann z.B. so aus:

Code Auswählen Erweitern

  # --------------------------------------------------------
  # Semantik für Wärmepumpen
  # -------------------------------------------------------- 
  semantics_heatpump_advanced => sub {
      my ($f) = @_;
      return [
          $f->{heating_degree_norm},                                   # Heizlast & Kühllast
          $f->{cooling_degree_norm},

          $f->{hp_heating_mode},                                       # WP-Modi
          $f->{hp_cooling_mode},

          $f->{ww_morning},                                            # Warmwasser-Semantik
          $f->{ww_evening},
          $f->{ww_cold_boost},
          $f->{ww_pv_boost},

          $f->{cop_proxy},                                             # COP-Semantik
          $f->{cop_inverse},
          $f->{hp_power_factor},

          $f->{frost_protect},                                         # Frostschutz
          $f->{frost_load},

          ....
      ];
  },

Sie werden gebildet durch Verknüpfungen:

Code Auswählen Erweitern

  # ---------------------------------------------------------
  # Heizlast + Kühllast (dynamische Komforttemp)
  # ---------------------------------------------------------
  my $t_comfort_norm      = $p->{temp_comfort_norm};                                      # normierte Komforttemp
  my $temp_norm_min       = ($range eq '-11') ? -1.0 : 0.0;                               # Normraum-Minimum bestimmen

  my $heating_raw         = $t_comfort_norm - $temp_norm;                                 # Roh-Heizlast
  $heating_raw            = 0 if($heating_raw < 0);

  my $heating_span        = $t_comfort_norm - $temp_norm_min;                             # Spannweite für Normierung
  $heating_span           = 1 if($heating_span <= 0);

  my $heating_degree_norm = $heating_raw / $heating_span;                                 # Normierte Heizlast
  $heating_degree_norm    = 0 if($heating_degree_norm < 0);
  $heating_degree_norm    = 1 if($heating_degree_norm > 1);
 
  my $cooling_raw         = $temp_norm - $t_comfort_norm;
  $cooling_raw            = 0 if($cooling_raw < 0);

  my $cooling_degree_norm = $cooling_raw / (1 - $t_comfort_norm);
  $cooling_degree_norm    = 0 if($cooling_degree_norm < 0);
  $cooling_degree_norm    = 1 if($cooling_degree_norm > 1);

  $sigs->{heating_degree_norm} = $heating_degree_norm;
  $sigs->{cooling_degree_norm} = $cooling_degree_norm;
  $sigs->{hp_heating_mode}     = ($heating_degree_norm > 0.1) ? 1 : 0;
  $sigs->{hp_cooling_mode}     = ($cooling_degree_norm > 0.1) ? 1 : 0;

  ....

Hier geht auch die Solltemperatur comforttemp, also die Zieltemperatur im Wohnraum, als Parameter ein. Die Semantiken semantics_heatpump_advanced brauchen aber noch weitere Verknüpfungen.
Für genauere Analysen brauche ich bitte das Trainingslog (mit Debug aiProcess) + die erreichten Kennwerte.

Lt. Theorie sollte aiConActFunc=GAUSSIAN, aiConTrainAlgo=RPROP, aiConSteepness >= 0.9, aiConShuffleMode=2 bei WP/EV die beste Wahl sein. Da ich beides nicht habe, bin ich auf eure Trainingsergebnisse angewiesen.  HINWEIS: EV wird noch nicht gut fuktionieren, hier fehlen noch die Vorbereitungen.

Für meinen Standardhaushalt mit PV + Bat passt es schon sehr gut.

[DS_Starter]

Update V 2.0.0 im Contrib vorgenommen:

- CO Abweichung wird berechnet und im UI dargestellt. (Readings Today_CONdeviation, Today_CONforecast, Today_CONreal)
- der Consumer Type heatpump ist beschrieben:

(*) Für Verbrauchertyp heatpump sind Besonderheiten zu beachten:

    power    maximale Leistungsaufnahme der Wärmepumpe in W. Der Wert darf nicht! 0 sein.
    etotal    Reading:Einheit (Wh/kWh) des Consumer Device, welches die Summe der verbrauchten Energie liefert. Die Angabe ist verpflichtend.
    pcurr    Reading:Einheit (W/kW) welches den aktuellen Energieverbrauch liefert. Die Angabe ist verpflichtend.
    comforttemp    Solltemperatur (Komforttemperatur) in den Wohnräumen in °C. Die Angabe ist verpflichtend.

[klaus.schauer]

Wohin unterscheidet sich type=heatpump vom den bisherigen Verfahren?
Welche Bedeutung hat comforttemp=20?

Bei heatpump wird die Feature Version "v2_hp_advanced" (aktivierte Registry Version: v2_hp_advanced) ausgewählt.
Dadurch wird ein Feature-Set mit WP spezifischen Semantiken zusätzlich zum Standard aktiviert.

Solche Semantiken sehen dann z.B. so aus:

Code Auswählen Erweitern

  # --------------------------------------------------------
  # Semantik für Wärmepumpen
  # -------------------------------------------------------- 
  semantics_heatpump_advanced => sub {
      my ($f) = @_;
      return [
          $f->{heating_degree_norm},                                   # Heizlast & Kühllast
          $f->{cooling_degree_norm},

          $f->{hp_heating_mode},                                       # WP-Modi
          $f->{hp_cooling_mode},

          $f->{ww_morning},                                            # Warmwasser-Semantik
          $f->{ww_evening},
          $f->{ww_cold_boost},
          $f->{ww_pv_boost},

          $f->{cop_proxy},                                             # COP-Semantik
          $f->{cop_inverse},
          $f->{hp_power_factor},

          $f->{frost_protect},                                         # Frostschutz
          $f->{frost_load},

          ....
      ];
  },

Sie werden gebildet durch Verknüpfungen:

Code Auswählen Erweitern

  # ---------------------------------------------------------
  # Heizlast + Kühllast (dynamische Komforttemp)
  # ---------------------------------------------------------
  my $t_comfort_norm      = $p->{temp_comfort_norm};                                      # normierte Komforttemp
  my $temp_norm_min       = ($range eq '-11') ? -1.0 : 0.0;                               # Normraum-Minimum bestimmen

  my $heating_raw         = $t_comfort_norm - $temp_norm;                                 # Roh-Heizlast
  $heating_raw            = 0 if($heating_raw < 0);

  my $heating_span        = $t_comfort_norm - $temp_norm_min;                             # Spannweite für Normierung
  $heating_span           = 1 if($heating_span <= 0);

  my $heating_degree_norm = $heating_raw / $heating_span;                                 # Normierte Heizlast
  $heating_degree_norm    = 0 if($heating_degree_norm < 0);
  $heating_degree_norm    = 1 if($heating_degree_norm > 1);
 
  my $cooling_raw         = $temp_norm - $t_comfort_norm;
  $cooling_raw            = 0 if($cooling_raw < 0);

  my $cooling_degree_norm = $cooling_raw / (1 - $t_comfort_norm);
  $cooling_degree_norm    = 0 if($cooling_degree_norm < 0);
  $cooling_degree_norm    = 1 if($cooling_degree_norm > 1);

  $sigs->{heating_degree_norm} = $heating_degree_norm;
  $sigs->{cooling_degree_norm} = $cooling_degree_norm;
  $sigs->{hp_heating_mode}     = ($heating_degree_norm > 0.1) ? 1 : 0;
  $sigs->{hp_cooling_mode}     = ($cooling_degree_norm > 0.1) ? 1 : 0;

  ....

Hier geht auch die Solltemperatur comforttemp, also die Zieltemperatur im Wohnraum, als Parameter ein. Die Semantiken semantics_heatpump_advanced brauchen aber noch weitere Verknüpfungen.
Für genauere Analysen brauche ich bitte das Trainingslog (mit Debug aiProcess) + die erreichten Kennwerte.

Lt. Theorie sollte aiConActFunc=GAUSSIAN, aiConTrainAlgo=RPROP, aiConSteepness >= 0.9, aiConShuffleMode=2 bei WP/EV die beste Wahl sein. Da ich beides nicht habe, bin ich auf eure Trainingsergebnisse angewiesen.  HINWEIS: EV wird noch nicht gut fuktionieren, hier fehlen noch die Vorbereitungen.

Für meinen Standardhaushalt mit PV + Bat passt es schon sehr gut.

Wenn ich das richtig verstehe, möchtest Du eine standardisierte und idealisierte Heiz-/Kühllast aus der variablen Außentemperatur und einer festen Raumtemperatur berechnen. Wenn das als Modell ausreichend genau sein sollte, so könnte man auf weitere Gebäude- oder Systemparameter verzichten. Andernfalls sind wir wieder bei meinem Ansatz weitere teils dynamische Parameter für diese -normierte- deterministische Berechnung einzubeziehen. Ich frage mich zudem, ob und wie die anderen aufgeführten Semantiken mit diesem einfachen Modell gefüllt werden sollen.

Für das weitere Training verwende ich jetzt die vorgeschlagenen Parameter.

[DS_Starter]

Andernfalls sind wir wieder bei meinem Ansatz weitere teils dynamische Parameter für diese -normierte- deterministische Berechnung einzubeziehen.

Auch wenn es momentan vllt. den Anschein hat, möchte ich keinesfalls auf deinen Ansatz verzichten sondern ihn in mein Legacy-Vorhersagemodell einbauen.
KI oder NN ist zwar wirklich eine feine Sache, aber es muß ja nicht in jedem Fall zum Besten Ergebnis führen. Deswegen hat man als Nutzer ja die Wahl und das möchte ich auch gleichberechtigt beibehalten (und auch mischen). Wir sehen ja bereits, wie unterschiedlich die Ergebnisse bei jedem von uns ausfallen. Es hängt auch von der Verfügbarkeit der Trainingsdaten und deren Güte ab. Wer erst mit dem Modul beginnt, hat keine Trainingsdaten und wird zwangsläufig mit dem Legacy-Modell arbeiten müssen.
Aber alles auf einmal kann ich nicht umsetzen, es braucht Zeit.

Wenn ich das richtig verstehe, möchtest Du eine standardisierte und idealisierte Heiz-/Kühllast aus der variablen Außentemperatur und einer festen Raumtemperatur berechnen.

Jein. Es geht nicht darum, eine exakte Heiz‑ oder Kühllast zu berechnen. Die Signale dienen eher als Trends und semantische Hinweise für das neuronale Netz. Man kann sich das so vorstellen, dass ich der KI darüber bestimmte Schwerpunkte oder Muster andeute, damit sie leichter erkennt, wann und warum ein Haushalt typischerweise heizt, kühlt oder Energie verbraucht.
Es sind also Signale und keine physikalisch exakten Heiz‑ oder Kühllasten. Sie helfen dem Modell eher dabei, typische Muster zu erkennen — also wann ein Haushalt wahrscheinlich heizt oder kühlt. Es sind Orientierungspunkte, die der KI das Lernen erleichtern.

[300P]

Update V 2.0.0 im Contrib vorgenommen:

- CO Abweichung wird berechnet und im UI dargestellt. (Readings Today_CONdeviation, Today_CONforecast, Today_CONreal)
- der Consumer Type heatpump ist beschrieben:

(*) Für Verbrauchertyp heatpump sind Besonderheiten zu beachten:

    power    maximale Leistungsaufnahme der Wärmepumpe in W. Der Wert darf nicht! 0 sein.
    etotal    Reading:Einheit (Wh/kWh) des Consumer Device, welches die Summe der verbrauchten Energie liefert. Die Angabe ist verpflichtend.
    pcurr    Reading:Einheit (W/kW) welches den aktuellen Energieverbrauch liefert. Die Angabe ist verpflichtend.
    comforttemp    Solltemperatur (Komforttemperatur) in den Wohnräumen in °C. Die Angabe ist verpflichtend.

Hab das mal im Wiki ergänzt

https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Beispiel_Sonderregistrierung_(ab_V2.0.0)_einer_Wärmepumpe

[klaus.schauer]

(*) Für Verbrauchertyp heatpump sind Besonderheiten zu beachten:

    power    maximale Leistungsaufnahme der Wärmepumpe in W. Der Wert darf nicht! 0 sein.
    etotal    Reading:Einheit (Wh/kWh) des Consumer Device, welches die Summe der verbrauchten Energie liefert. Die Angabe ist verpflichtend.
    pcurr    Reading:Einheit (W/kW) welches den aktuellen Energieverbrauch liefert. Die Angabe ist verpflichtend.
    comforttemp    Solltemperatur (Komforttemperatur) in den Wohnräumen in °C. Die Angabe ist verpflichtend.

Ein Hinweis zu etotal: Bei der Vaillant Wärmepumpe, die hier in Betrieb ist, wird etotal nur einmal am Tag kurz nach Mitternacht aktualisiert. Wenn etotal für die stündliche Berechnung der Energie gebraucht wird, müsste man dies aus den Leistungsdaten aufsummieren.

[300P]

PS:
In vielen Herstellerforen wird immer wieder mal von Usern darauf hingewiesen das die "berechneten" Werte der Hersteller schon mal mehr oder weniger bei Energiewerten für Strom- / Wärmemengen und den gemessenen realen Werten stark daneben liegen.
Auch werden oft nicht alle Teile (wie HK-Pumpen / Begleitheizungen etc) der WP mit erfasst.

Deshalb nutzen eingefleischte Nutzer u.a. für die Wertermittlung inzwischen EM für Strom - über alle 3 Phasen am Unterverteiler vor der WP-Heizung - und WMZ für die erzeugten Wärmemengen.
Da werden manchmal aus tollen COP-Labor-Herstellerwerten am Ende dann ganz normale kleine JAZ...... genauso wie bei den Spritverbrauchsangaben der Hersteller für PKW. 

[klaus.schauer]

PS:
In vielen Herstellerforen wird immer wieder mal von Usern darauf hingewiesen das die "berechneten" Werte der Hersteller schon mal mehr oder weniger bei Energiewerten für Strom- / Wärmemengen und den gemessenen realen Werten stark daneben liegen.
Auch werden oft nicht alle Teile (wie HK-Pumpen / Begleitheizungen etc) der WP mit erfasst.

Deshalb nutzen eingefleischte Nutzer u.a. für die Wertermittlung inzwischen EM für Strom - über alle 3 Phasen am Unterverteiler vor der WP-Heizung - und WMZ für die erzeugten Wärmemengen.
Da werden manchmal aus tollen COP-Labor-Herstellerwerten am Ende dann ganz normale kleine JAZ...... genauso wie bei den Spritverbrauchsangaben der Hersteller für PKW.

Erbsenzähler gibt es überall. Die Daten zum Energieverbrauch die die Wärmepumpe (Vaillant) und das Energiemanagementsystem (SMA Homemanager 2.0) liefern, passen recht gut zusammen. Ebenso wie der Vergleich zwischen dem Verbrauch des ehemaligen Brennwertkessels mit der berechneten erzeugten Energie der Wärmepumpe heute. Aber es muss klar sein, dass es sich um berechnete Werte handelt, die eben größere Toleranzen haben, als geeichte Zähler. Wie vielschichtig dies ist, sehen wir doch hier im SolarForecast-Projekt. Deswegen wittere ich doch nicht gleich Unfähigkeit oder gar Betrug.

Übrigens liege ich mit den Verbräuchen meines alten Diesel-PKW immer im vom Hersteller angegebenen Bereich. Woran liegt das wohl, wenns mehr wird?

[klaus.schauer]

Andernfalls sind wir wieder bei meinem Ansatz weitere teils dynamische Parameter für diese -normierte- deterministische Berechnung einzubeziehen.

Auch wenn es momentan vllt. den Anschein hat, möchte ich keinesfalls auf deinen Ansatz verzichten sondern ihn in mein Legacy-Vorhersagemodell einbauen.
Aber alles auf einmal kann ich nicht umsetzen, es braucht Zeit.

Wenn ich das richtig verstehe, möchtest Du eine standardisierte und idealisierte Heiz-/Kühllast aus der variablen Außentemperatur und einer festen Raumtemperatur berechnen.

Jein. Es geht nicht darum, eine exakte Heiz‑ oder Kühllast zu berechnen. Die Signale dienen eher als Trends und semantische Hinweise für das neuronale Netz. Man kann sich das so vorstellen, dass ich der KI darüber bestimmte Schwerpunkte oder Muster andeute, damit sie leichter erkennt, wann und warum ein Haushalt typischerweise heizt, kühlt oder Energie verbraucht.
Es sind also Signale und keine physikalisch exakten Heiz‑ oder Kühllasten. Sie helfen dem Modell eher dabei, typische Muster zu erkennen — also wann ein Haushalt wahrscheinlich heizt oder kühlt. Es sind Orientierungspunkte, die der KI das Lernen erleichtern.

Keine Sorge ich will meine Berechnungen nicht "retten". Diese können nur mehr oder weniger statische Werte liefern. Wenn es gelingen sollte, die KI mit ganz einfachen Modellen auf den Pfad der Tugend zu bringen, wäre der Rest Zeitverschwendung.

Die Grenzen zeigen die Berechnungen von heute, siehe Diagramm. Während des Tages passt es recht gut, weil die Wärmepumpe bei den niedrigen Temperaturen nahezu konstant durchläuft. Während der Nachtstunden passt es aber nicht, weil die Wärmepumpe sich in dem eingestellten Betriebsmodus dann ganz ausschaltet oder auf Frostschutz wechselt. In der Hochlaufphase am Morgen gibt es grobe Ausreißer, da ich im "Niedrigtarif" den Pufferspeicher aufheize und danach einige Zeit später die Heizkreise hochlaufen.