Neueste Beiträge

#91

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 07 Januar 2026, 20:49:05

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

#92

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von lorisurfen - 07 Januar 2026, 20:44:28

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?

#93

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von klaus.schauer - 07 Januar 2026, 20:19:18

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


#94

readingsGroup / readingsHistory / Aw: ReadingsGroup Leeres Readi...

Letzter Beitrag von Damu - 07 Januar 2026, 20:11:49

supper einfach.
Vielen Dank.

#95

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 07 Januar 2026, 20:05:26

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.

#96

Homematic / Aw: Heizung schalten

Letzter Beitrag von Beta-User - 07 Januar 2026, 19:55:27

Hallo zurück.

Da ich grade auch für ein Familienmitglied am Rumüberlegen bin, wie man eine bisher (komplett) "dumme" Fußbodenheizung einem update unterziehen könnte, hier mal ein paar Gedanken:

Es gibt u.a. das Modul "PWMR", siehe Fussbodenheizung mit PWM steuern. Damit könnte man schon am Ziel sein .

Falls es direkte Kabelverbindungen von (ehemaligen) Raumthermostaten zum Verteiler geben sollte, würde ich allerdings eher dazu tendieren, die Raumthermostate "smart" zu machen, wobei hier "BEOK" ein erprobtes Stichwort wäre - ich würde in dem Fall allerdings dann zu einem ZigBee-Thermostat greifen (willkürlich gegriffen z.B.: https://www.zigbee2mqtt.io/devices/TS0601_floor_thermostat.html).

Im hiesigen Fall gibt es leider keine Leitungen, von daher wäre mir eigentlich ein ZigBee-Raumthermostat iVm. einem ZigBee-Verteilerbaustein die "liebste" Lösung - sowas scheint es aber nur von einer (mir bisher unbekannten) Firma zu geben (EONE, https://www.zigbee2mqtt.io/devices/EONE-230W.html und https://www.zigbee2mqtt.io/devices/ECB62-ZB.html#engo-ecb62-zb).

Ansonsten lese ich einfach mal mit, vielleicht übersehe ich was wesentliches...

[hatte]

#97

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von 300P - 07 Januar 2026, 19:54:29

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

#98

readingsGroup / readingsHistory / Aw: ReadingsGroup Leeres Readi...

Letzter Beitrag von ph1959de - 07 Januar 2026, 19:48:51

Das sollte mit einem "!" vor dem Reading gehen.

[must]

#99

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von lorisurfen - 07 Januar 2026, 19:43:56

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 ?

#100

Homematic / Heizung schalten

Letzter Beitrag von elogger - 07 Januar 2026, 18:49:33

Hallo zusammen,

ich habe hier im Haus etliche "HM-TC-IT-WM-W-EU" verbaut, die über Peering die FBH schalten. Dafür sind die FBH-Ventilen an einige "HM-LC-SW4-DR" angeschlossen. Das läuft gut seit vielen Jahren.

Jetzt gibt es im Keller ein paar Heizkreise, die bisher nicht genutzt wurden und in deren Räumen nur entweder alte oder billige Temperaturfühler verbaut sind. Es sind 2x "HM-CC-TC" und 2x LaCrosse JeeLink "TX35DTH-IT".

Wie kann ich die Temperaturwerte der "HM-CC-TC" und "TX35DTH-IT" nutzen um über die an "HM-LC-SW4-DR" angeschlossenen FBH-Ventile die Wärmezufuhr zu steuern? Ein Peering finde ich da als Möglichkeit nicht. Wer kann mir hier einen Tipp geben und helfen?

Danke, Martin