76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[lorisurfen]

Hallo lorisurfen,

erstmal willkommen im Club. 

Es ist heute schon spät und dein Anliegen wahrscheinlich nicht ganz schnell abzuarbeiten.

SF 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:
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)

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:

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

Hallo,
Danke für die Rückmeldung und support.
Ich habe jetzt batteryPreferredCharge=4 gesetzt und dafür den consumer mit mode=can angelegt (siehe code):

Code Auswählen Erweitern

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.
Ich dachte mit mintime=SunPath bleibt der planningstate bis Sonnenuntergang ?

[300P]

....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...

Inzwischen ist das nur noch so weil es sich eingebürgert hat das so ab 05:30 WW "schön heiß" ist und auch das Bad für die Frühduscher ab 05:30 Uhr angenehm mollig warm ist.  

[DS_Starter]

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.
Ich dachte mit mintime=SunPath bleibt der planningstate bis Sonnenuntergang ?

So ist es auch.
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.

[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.

Hier die Ergebnisse mit den vorgeschlagenen Einstellungen und den Standardwerten vorher, sowie ein LOG. Scheint nicht berauschend zu sein.

Code Auswählen Erweitern

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: -


[lorisurfen]

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.
Ich dachte mit mintime=SunPath bleibt der planningstate bis Sonnenuntergang ?

So ist es auch.
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.

Wenn 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?
Wenn ich also nur temporär und nicht für den restlichen Tag unterbrechen möchte (z.B. wegen Wolke/temporär Batterie aufladen) müsste ich statt swoffcond die Bedingung für Unterbrechnung über Schlüssel
auto=automatic oder
interruptable
steuern?

[DS_Starter]

@Klaus, hier ist eine Log/Kennwert-Bewertung:

Code Auswählen Erweitern


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.

Letztendlich werde ich versuchen weitere Signale einzubauen.

[DS_Starter]

Wenn ich also nur temporär und nicht für den restlichen Tag unterbrechen möchte (z.B. wegen Wolke/temporär Batterie aufladen) müsste ich statt swoffcond die Bedingung für Unterbrechnung über Schlüssel
auto=automatic oder
interruptable
steuern?

Ja, mit interruptable. automatic ist dafür nicht geeignet. Es ist eher eine Freischaltung. Z.B. wenn der Verbraucher "on" ist und dann automatic ausgeschaltet wird, kann das Modul den Consumer nicht mehr steuern. Kann gewollt sein, aber in diesem Kontext eher nicht zutreffend.

[DS_Starter]

Ich habe weitere WP-Semantiken eingebaut und das Modul im Contrib upgedated.
Wer es ausprobieren möchte verwendet wegen der Vergleichbarkeit:

aiConActFunc    SIGMOID
aiConMomentum   0.5
aiConTrainAlgo  INCREMENTAL
aiConSteepness  0.9

Ich komme aktuell über den gesamten Tag auf eine CO-Abweichung von 3,8%.

LG,
Heiko

[grappa24]

Hier noch mein Log vom heutigen Training (debug aiProcess) und die anschließenden Prognose und Verbrauchswerte:

https://1drv.ms/t/c/b03433bb7f8ba74d/IQBKmY283_31Rp62xok9JC-WASwEUvURpCGyBbHT0H9hYis?e=9lL1Pw

Um 14:17 war das Training zu Ende und der hohe Verbrauch in der 20.ten Stunde kommt vom PV-Laden.

[stefanru]

Hi Heiko,

sorry ich habe nicht alles gelesen.
Habe meine WP auch eingebunden und AI Training gemacht.
Kannst du mir schnell sagen wie ich die Anzeige im Header für die CO Abweichung bekomme wie in deinem Screenshot?

Danke und Gruß,
Stefan

[DS_Starter]

@Dieter, danke Log schaue ich mir morgen an.

@Stefan, du brauchst nur die aktuelle V 2.0.0 aus meinem cContrib zu laden. Dann kommt der Eintrag automatisch im UI. Ist nichts einzustellen.

[klaus.schauer]

@Klaus, hier ist eine Log/Kennwert-Bewertung:

Code Auswählen Erweitern


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.

Letztendlich werde ich versuchen weitere Signale einzubauen.

Ich hatte zwei Auswertungen hinterlegt:
- AI training: 2026-01-07 19:46:49: mit den empfohlenen WP-Werten
- AI training: 2026-01-07 11:11:21; mit den Standardwerten

Die Bewertung bezieht sich auf den Standardfall. Empfohlene WP-werte:

Code Auswählen Erweitern

aiConActFunc=GAUSSIAN aiConTrainAlgo=RPROP aiConSteepness=0.9 aiConShuffleMode=2
Soweit ich das beurteilen kann, sind die Ergebnisse mit den Standardwerten und ohne die neuen speziellen WP-Semantiken dann wohl besser gewesen. Wie machen wir weiter?

Hier nochmal die Ergebnisse des letzten Trainings heute Nacht:

Code Auswählen Erweitern

last AI training: 2026-01-08 02:27:31 / Runtime in seconds: 435
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: 2686 Datensätze (Training=2148, Validierung=538)
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: 148 (von max. 15000)
Training MSE: 0.000209
Validation MSE: 0.003757
Validation MSE Average: 0.012170
Validation MSE Standard Deviation: 0.000624
Validation Bit_Fail: 0
Model Bias: 192 Wh
Model Slope: 0.7
Trainingsbewertung: Retrain

=== Fehlermaße der Prognosen ===

MAE: 509.57 Wh
MedAE: 217.33 Wh
RMSE: 728.52 Wh
RMSE relative: 52 %
RMSE Rating: very bad
MAPE: 25.67 %
MdAPE: 19.86 %
R²: 0.69

=== Drift-Kennzahlen ===

Drift Score: -
Drift RMSE relative: -
Drift Bias: -
Drift Slope: -
Drift Bewertung: -


[Wolle02]

Moin Heiko,

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.

Ich hatte das in einem Anwendungsfall auch schon mal und habe es dann irgendwie anders gelöst, aber grundsätzlich fand ich es auch unpraktisch, dass der Zyklus dann einfach abgeschlossen ist. Wäre es eventuell möglich einen zusätzlichen Schlüssel z.B. replan=1 einzufügen, der eine sofortige Neuplanung einleitet, wenn der Zyklus abgeschlossen ist?

Gruß
Wolle

[DS_Starter]

Moin zusammen,

@Klaus,

Soweit ich das beurteilen kann, sind die Ergebnisse mit den Standardwerten und ohne die neuen speziellen WP-Semantiken dann wohl besser gewesen. Wie machen wir weiter?

Dann trainieren mit den Standardwerten. Die WP-Semantiken sind trotzdem aktiv sobald eine WP definiert und erkannt wird.
Die Einstellungen für das Modelltreining in aiControl - also aiConActFunc, aiConTrainAlgo, aiConSteepness, aiConShuffleMode usw. - sind davon unabhängig. So einstellen wie im individuellen Umfeld die besten Ergebnisse erzielt werden können.

@Wolle,

Wäre es eventuell möglich einen zusätzlichen Schlüssel z.B. replan=1 einzufügen, der eine sofortige Neuplanung einleitet, wenn der Zyklus abgeschlossen ist?

Das wäre möglich. Allerdings wirkt es dann natürlich ständig, sodass man eigentlich nur mit interuptable arbeiten bräuchte um den gleichen Effekt zu erzielen.
Aktuell habe ich dafür den Befehl "set <name> consumerNewPlanning XX" vorgesehen.
Die Idee dahinter ist, dass der User z.B. mit einem notify, DOIF auf einen finished-Status reagieren und über diesen Befehl direkt eine Neueinplanung vornehmen kann. Das ist wesentlich flexibler, weil man z.B. die täglichen Neueinplanungen auf 3 begrenzen oder von Zusatzbedingungen abhängig gestalten kann.

LG,
Heiko

[Wolle02]

Das wäre möglich. Allerdings wirkt es dann natürlich ständig, sodass man eigentlich nur mit interuptable arbeiten bräuchte um den gleichen Effekt zu erzielen.
Aktuell habe ich dafür den Befehl "set <name> consumerNewPlanning XX" vorgesehen.
Die Idee dahinter ist, dass der User z.B. mit einem notify, DOIF auf einen finished-Status reagieren und über diesen Befehl direkt eine Neueinplanung vornehmen kann. Das ist wesentlich flexibler, weil man z.B. die täglichen Neueinplanungen auf 3 begrenzen oder von Zusatzbedingungen abhängig gestalten kann.

Ich weiß ehrlich gesagt das genaue Szenario nicht mehr, aber mir ist im Hinterkopf geblieben, dass es in diesem Fall hilfreich gewesen wäre so einen Schlüssel für eine sofortige Neuplanung zu haben.
Natürlich kann man das auch mit einem notify lösen; aber dafür bräuchte man dann auch wieder ein neues Device. Irgendwann wirds mal unübersichtlich. Ich versuche eigentlich immer alles was geht innerhalb eines Devices zu lösen. Klappt nicht immer, aber ich versuche die Menge der Devices zu begrenzen, weil ich mittlerweile merke, dass ich mich verzettle und immer schauen muss wo ich jetzt was regulatorisch gemacht habe.
Kann man anders sehen, ich weiß.