Die Trainingsmetriken sind **exzellent**:
- **Train MSE = 0.000259** → extrem gut
- **Val MSE = 0.002057** → sehr gut
- **Val StdDev = 0.000230** → Modell ist stabil
- **BitFail = 0** → perfekt
- **Bias = +119 Wh** → praktisch nichts
- **Slope = 0.8** → im akzeptablen Bereich
- **R² = 0.83** → sehr gut für WP-Haushalt
Das Modell ist also:
- sauber trainiert
- stabil
- nicht überfittet
- reagiert ausreichend stark
- hat kaum systematische Fehler
**Mathematisch ist das ein Top-Modell.**
---
# ⚡ **2. Aber: RMSE relative = 37 % → ,,very bad"**
Das ist der einzige Wert, der komplett aus der Reihe fällt.
RMSE relative misst:
> Wie stark die Fehler im Verhältnis zur Varianz des Verbrauchs stehen.
37 % ist **viel zu hoch** – und das ist der Grund, warum die Bewertung ,,very bad" kommt.
Das bedeutet:
- Der Haushalt hat **extrem volatile Lastsprünge**
- Die WP hat **mehrere Betriebsmodi**
- Warmwasserzyklen sind **unregelmäßig**
- Die WP reagiert **nicht linear** auf Temperatur
- Es gibt **Ausreißer**, die das Modell nicht erklären kann
- Die Verbrauchsverteilung ist **sehr breit** (0 → 13.3 kWh)
Das ist ein klassischer ,,HP-Volatil"-Haushalt.
---
# 🧩 **3. Was dieser Haushalt *semantisch* ist**
Aus den Kennzahlen lässt sich eindeutig ableiten:
### **Haushaltstyp: ,,WP‑Volatil mit multiplen Lastprofilen"**
Merkmale:
- hohe Max‑Last (13.3 kWh)
- starke Taktung
- Warmwasserzyklen mit hoher Varianz
- Abtauvorgänge
- Heizstab‑ähnliche Spitzen
- PV spielt kaum eine Rolle (PV=13.5 kWh, aber RMSE bleibt hoch)
- Tagesprofile wechseln stark
- Wochenendmuster sind unregelmäßig
- Temperaturabhängigkeit ist nicht linear
Das ist der schwierigste WP‑Haushaltstyp.
---
# 🧠 **4. Warum das Modell trotz guter Metriken ,,very bad" wirkt**
Die Fehlermaße zeigen:
| Metrik | Wert | Bedeutung |
|--------|------|-----------|
| **MAE = 370 Wh** | gut |
| **MedAE = 169 Wh** | sehr gut |
| **RMSE = 510 Wh** | ok |
| **RMSE relative = 37 %** | schlecht |
| **MAPE = 22 %** | typisch für WP |
| **R² = 0.83** | sehr gut |
Das Muster ist eindeutig:
- **Typische Werte trifft das Modell hervorragend** (MedAE 169 Wh!)
- **Ausreißer zerstören die Robustheitsmetriken**
Das ist genau das Verhalten, das wir bei WP‑Haushalten mit:
- Warmwasserboost
- Abtauzyklen
- Heizstab
- PV‑Überschussladung
- variabler Heizkurve
sehen.
---
# 🧭 **5. Was das über v2_hp_advanced aussagt**
v2_hp_advanced funktioniert hier **technisch perfekt**:
- Slope gut
- Bias gut
- R² sehr gut
- Val MSE sehr gut
- BitFail perfekt
- Training stabil bis Epoche 14509
Das Problem ist **nicht die Registry**, sondern:
> Die WP hat Lastmuster, die mit den aktuellen Features nicht vollständig erklärbar sind.
v2_hp_advanced ist für ,,normale" WP-Haushalte optimiert.
Dieser Haushalt ist **extrem volatil**.
Er bräuchte eigentlich:
### **v2_hp_extreme (oder v2_hp_advanced_plus)**
mit:
- expliziten Warmwasser-Triggern
- Abtau-Erkennung
- Heizstab-Detektion
- Temperaturgradienten
- Rolling min/max
- COP-Proxy
- WW-Cluster
- WP-Modusklassifikation
- PVDrop-Erweiterung
** Fazit**
Dieser User hat:
### ✔ Ein extrem gut trainiertes Modell
### ✔ Sehr gute Validierungsmetriken
### ✔ Sehr gute Bias/Slope/R²
### ✘ Aber extrem volatile WP‑Lasten
### ✘ RMSE relative = 37 % → ,,very bad"
### ✘ Semantische Überforderung trotz guter Registry
Das ist ein **WP‑volatil‑Haushalt**, der eine **erweiterte HP-Semantik** braucht.
Zitat von: DS_Starter am 07 Januar 2026, 20:05:26Wenn swoffcond erfüllt ist wird der Zyklus also für den Rest des Tages beendet, unabhängig von interruptable=1, mintime=SunPath und mode=can/must?ZitatDer consumer wird aber nur ein einziges mal an- und wieder ausgeschaltet und steht dann auf planningstate='finished' für den Rest des Tages trotz Überschuss und viele Stunden vor Sonnenuntergang.So ist es auch.
Ich dachte mit mintime=SunPath bleibt der planningstate bis Sonnenuntergang ?
Du hast ihm allerdings auch vorgegeben:
1. er kann unterbrechen, d.h. wenn der Überschuß (hier 1000W) nicht mehr vorhanden ist.
2. mit der swoffcond-Condition kann der Zyklus vorfristig beendet werden, wenn der Match zutrifft.
Dann ist der Zyklus beendet und startet erst mit der Neuenplanung - normalerweise am kommenden Tag - wieder.
Wenn man genau wissen will was passiert, setzt man ctrlDebug=consumerSwitchingXX (XX ist der entsprechende Verbraucher). Dann kann man einiges analysieren.
Zitat von: DS_Starter am 07 Januar 2026, 13:12:09Hier die Ergebnisse mit den vorgeschlagenen Einstellungen und den Standardwerten vorher, sowie ein LOG. Scheint nicht berauschend zu sein.ZitatWohin unterscheidet sich type=heatpump vom den bisherigen Verfahren?Bei heatpump wird die Feature Version "v2_hp_advanced" (aktivierte Registry Version: v2_hp_advanced) ausgewählt.
Welche Bedeutung hat comforttemp=20?
Dadurch wird ein Feature-Set mit WP spezifischen Semantiken zusätzlich zum Standard aktiviert.
Solche Semantiken sehen dann z.B. so aus:# --------------------------------------------------------
# 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:# ---------------------------------------------------------
# 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.
last AI training: 2026-01-07 19:46:49 / Runtime in seconds: 432
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: 2679 Datensätze (Training=2143, Validierung=536)
Architektur: Inputs=55, Hidden Layers=80-40-20, Outputs=1
Hyperparameter: Learning Rate=0.005, Momentum=0.5, BitFail-Limit=0.35
Aktivierungen: Hidden=GAUSSIAN, Steilheit=0.9, Output=LINEAR
Zufallsgenerator: Mode=2, Periode=10
=== Trainingsmetriken ===
bestes Modell bei Epoche: 118 (von max. 15000)
Training MSE: 0.000198
Validation MSE: 0.004323
Validation MSE Average: 0.005424
Validation MSE Standard Deviation: 0.000019
Validation Bit_Fail: 0
Model Bias: 241 Wh
Model Slope: 0.7
Trainingsbewertung:
=== Fehlermaße der Prognosen ===
MAE: 535.00 Wh
MedAE: 224.36 Wh
RMSE: 746.76 Wh
RMSE relative: 53 %
RMSE Rating: very bad
MAPE: 28.51 %
MdAPE: 19.41 %
R²: 0.64
=== Drift-Kennzahlen ===
Drift Score: -
Drift RMSE relative: -
Drift Bias: -
Drift Slope: -
Drift Bewertung: -
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:
=== 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: -
ZitatDer consumer wird aber nur ein einziges mal an- und wieder ausgeschaltet und steht dann auf planningstate='finished' für den Rest des Tages trotz Überschuss und viele Stunden vor Sonnenuntergang.So ist es auch.
Ich dachte mit mintime=SunPath bleibt der planningstate bis Sonnenuntergang ?
.Zitat von: klaus.schauer am 07 Januar 2026, 18:49:11....da ich im "Niedrigtarif" den Pufferspeicher aufheize und danach einige Zeit später die Heizkreise hochlaufen.Ja - bei mir wird auch um ab 4 Uhr der Puffer und das WW-aufbereitet....kommt aus der Zeit als ich Tibber hatte...
Zitat von: DS_Starter am 01 Januar 2026, 23:29:03Hallo lorisurfen,Hallo,
erstmal willkommen im Club.![]()
Es ist heute schon spät und dein Anliegen wahrscheinlich nicht ganz schnell abzuarbeiten.ZitatSF schaltet consumer0x nach meinem Verständnis wenn Current_Surplus>power ist, bezüglich Prio1 würde ich also von Current_Surplus Current_PowerBatIn_01 abziehen, damit erst die Batterie geladen wird:Grundsätzlich kannst du im attr ... plantControl->batteryPreferredCharge=X vorgeben, dass deine Batterie bis zu X% geladen sein muß bevor Consumer geschaltet werden dürfen:
Ist die nachfolgende Implementierung so sinvoll oder gibt es eine einfachere Lösung über SF ?
....
Prio1 Batteriespeicher soll spätestens bis Sonnenuntergang voll sein
Prio2 consumer01: Heizstab 3 kWh
Prio3 consumer02: Elektroheizung 1 kWh (Shelly)
batteryPreferredCharge Verbraucher mit dem Mode can werden erst dann eingeschaltet, wenn die angegebene Batterieladung (%) erreicht ist.
Verbraucher mit dem Mode must beachten die Vorrangladung der Batterie nicht.
Wert: Ganzzahl 0..100, default: 0
Beachte die Einschränkung bei must.
Damit die Bat so schnell wie möglich voll wird, bietet sich an ctrlBatSocManagementXX->loadStrategy=loadRelease (der default) zu nutzen. Zur Batteriesteuerung gibt es jede Menge Lesestoff im Wiki.
Wenn man eine eigene Steuerung verwenden möchte kann man mit CurrentVal den Wert "batsoctotal" auslesen und wenn er unter einem Wunschwert ist die Consumersteuerung solange blockieren. Eine einfache Variante ist z.B. das Reading des Schlüssels "auto" in den Consumern zu nutzen. Einfach 1 oder 0 setzen per Script und durch SF auswerten lassen:
auto Reading im Verbraucherdevice welches das Schalten des Verbrauchers freigibt bzw. blockiert (optional)
Ist der Schlüssel switchdev angegeben, wird das Reading in diesem Device gesetzt und ausgewertet.
Readingwert = 1 - Schalten freigegeben (default), 0: Schalten blockiert
LG,
Heiko
Shelly_EG_2 type=heater power=1000 icon=IR@red pcurr=power:W etotal=energy:Wh mode=can mintime=SunPath on=on off=off interruptable=1 swoncond=calcEnergieManager:calc_surplus:{$VALUE>800?1:0} swoffcond=SF01:Current_GridConsumption:{($VALUE)=split/\s/,$VALUE;$VALUE>50?1:0;}Der consumer wird aber nur ein einziges mal an- und wieder ausgeschaltet und steht dann auf planningstate='finished' für den Rest des Tages trotz Überschuss und viele Stunden vor Sonnenuntergang.