Zitat von: DS_Starter am 09 März 2026, 19:57:50Hallo Denis,
dein Konstrukt ist wahrscheinlich Neuland im SF-Umfeld.
Ich habe mir die Darstellungen des Zendure Balkonfraftwerk mit SolarHub2000 im Inet angeschaut und es könnte folgendermaßen funktionieren.
setupInverterDev01 und setupInverterDev02 ergänzt du mit einem setupBatteryDev01.
Dabei ist setupInverterDev01 der SolarHub2000 (Typ Solar-Ladegerät in SF). Dazu gehört noch setupBatteryDev01, wobei hier vermutlich ebenfalls Werte aus dem SolarHub2000 zugeordnet werden. Die Inhalte von pvOut, pin, pout siehst du im Beitrag zuvor.
Dann legst du noch setupInverterDev02 als Typ Batterie-Wechselrichter an, der die Verbindung vom SolarHub2000 zum Hausnetz realisiert. Ein Batterie-Wechselrichter wird durch strings=none aktiviert und hat nur die Anschlüsse ac2dc bzw. dc2ac. Bei dir dürfte nur dc2ac relevant sein und sollte die Summe aus pout + (pvOut - pin) enthalten.
Wenn du damit erfolgreich deine Anlage einrichten konntest, wäre es sicherlich einen Beitrag im Wiki wert.
LG,
Heiko
Zitat von: toggle1 am 01 März 2026, 11:02:09Wie im Optimierungs-Thread geschrieben, habe ich mal wieder das Problem mit dem klemmenden Stellventil in der MFG. Wenn der Stellmotor noch funktionstüchtig ist, kann man dem Ventil während der WW-Bereitung im "Fachmann"-Menü nachhelfen (Stellventil WW an, Stellventil WW aus). Das wollte ich automatisieren. Mit einem CAN-Bus-Adapter habe ich die Kommunikation am Bedienteil belauscht und dabei sind folgende CAN-Messages rausgekommen:great job //thanks for this reverse engineering
1 11850.881 DT 069E Rx 7 30 00 FA 06 53 00 01 => WW an
2 15302.915 DT 069E Rx 7 30 00 FA 06 53 00 00 => WW aus
3 21428.419 DT 069E Rx 7 30 00 FA 06 52 00 01 => HZ an
4 29904.865 DT 069E Rx 7 30 00 FA 06 52 00 00 => HZ aus
Ich habe dann die Bereiche 0x0A, 0x0B, 0x0C darauf getestet und fand die Daten in
0x0A0652 Stellventil in Heizposition
0x0A0653 Stellventil in WW-Position
Beide Register sind 16-bittig (wie oben im CAN-Trace)
Der Stellmotor sollte nicht allzu lange aktiviert werden. 30 Sekunden nach der Aktivierung vom WW-Icon aktiviere ich den Stellmotor für 3 Sekunden. Beide Zeitwerte sind willkürlich ausgewählt worden. Mal schauen, wie lange die MFG das noch mitmacht (ich bediente sie manuell die letzten 2 Wochen).
Nach der Aktivierung vom Stellmotor im WW-Betrieb hört man Motorgeräusche und anschließend ein leises Plopp-Geschräusch. Natürlich funktioniert es nur, wenn das Stellventil schon fast in der richtigen Position ist. Prinzipiell geht es ja nur darum, das Stellventil in die Endposition zu bringen, so dass der WW-Kreislauf komplett geschlossen wird.
WICHTIG: Man sollte es nicht mit einer funktionierenden MFG ausprobieren. Falls der Stellmotor zum falschen Zeitpunkt (z.B. Umschalten unter Druck) bedient wird, kann die Anlage beschädigt werden.
Informationen zum neuronalen Netz der Verbrauchsvorhersage
letztes KI-Training: 11.03.2026 08:59:06 / Laufzeit in Sekunden: 2952
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 76.73 ms
Verbrauchernummer Wärmepumpe: 08
=== Modellparameter ===
Normierungsgrenzen: PV=16071 Wh, Hausverbrauch: Min=0 Wh / Max=7598 Wh
Trainingsdaten: 7944 Datensätze (Training=6355, Validation=1589)
Architektur: Inputs=98, Hidden Layers=80-40, Outputs=1
Hyperparameter: Learning Rate=0.001, Momentum=0.6, BitFail-Limit=0.18
Aktivierungen: Hidden=GAUSSIAN_SYMMETRIC, Steepness=1.0, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Registry Version=v1_heatpump_active_pv
Zufallsgenerator: Mode=1, Period=20
=== Trainingsmetriken ===
bestes Modell bei Epoche: 208 (max. 15000)
Training MSE: 0.003919
Validation MSE: 0.003589
Validation MSE Average: 0.007856
Validation MSE Standard Deviation: 0.000391
Validation Bit_Fail: 7
Model Bias: 51 Wh
Model Slope: 0.9
Trainingsbewertung: Retrain
=== Fehlermaße der Prognosen ===
MAE: 355.96 Wh
MedAE: 293.28 Wh
RMSE: 407.60 Wh
RMSE relative: 19 %
RMSE Rating: excellent
MAPE: 18.27 %
MdAPE: 14.10 %
R²: 0.72
=== Rauschen ===
Rauschen Bewertung: low## Analyse des neuesten Trainings (11.03.2026, SolarForecast 2.3.1)
Die aktuelle Konfiguration zeigt eine **klare Verbesserung der Modellkalibrierung**, während die Prognosegüte im Wesentlichen stabil bleibt.
---
# 1. Trainingsstabilität
| Kennzahl | Wert | Bewertung |
| -------------------- | -------- | ------------- |
| Training MSE | 0.003919 | normal |
| Validation MSE | 0.003589 | sehr gut |
| Val/Train Verhältnis | ~0.92 | ausgezeichnet |
| Validation Std | 0.000391 | sehr stabil |
| BitFail | 7 | moderat |
**Interpretation**
* Validation-Fehler liegt **unter dem Trainingsfehler** → gute Generalisierung.
* Sehr kleine Standardabweichung zeigt ein **stabiles Modell**.
* Bestes Modell bereits bei **Epoche 208** → schnelle Konvergenz.
Das Trainingsverhalten ist damit **sehr sauber**.
---
# 2. Prognosequalität
| Kennzahl | Wert |
| ------------ | --------- |
| MAE | 355.96 Wh |
| RMSE | 407.60 Wh |
| RMSE relativ | 19 % |
| MAPE | 18.27 % |
| R² | 0.72 |
Diese Werte sind **nahezu identisch zum letzten Training**.
Interpretation:
* Modell ist **konvergiert**.
* Weitere große Verbesserungen sind mit gleicher Architektur unwahrscheinlich.
Für eine Wärmepumpen-Lastprognose im Haushalt ist:
**RMSE ~400 Wh bei Max ~7600 Wh → technisch gut.**
---
# 3. Wichtigste Verbesserung: Kalibrierung
| Kennzahl | vorher | jetzt |
| -------- | ------ | --------- |
| Bias | 404 Wh | **51 Wh** |
| Slope | 0.80 | **0.90** |
Das ist die **entscheidende Verbesserung**.
### Bias
Vorher:
```
systematische Überschätzung
```
Jetzt:
```
Bias ≈ 0
```
Das Modell ist praktisch **unbiased**.
### Slope
Vorher:
```
Peak-Kompression
```
Jetzt:
```
0.9 → deutlich bessere Amplitudenabbildung
```
Die Prognosen folgen dem realen Verbrauch **realistischer**.
---
# 4. Fehlerverteilung
Aus MAE und RMSE lässt sich abschätzen:
```
RMSE / MAE ≈ 1.14
```
Das bedeutet:
* relativ **kompakte Fehlerverteilung**
* **keine schweren Ausreißer**
Das ist ein gutes Zeichen für Stabilität.
---
# 5. BitFail-Analyse
| Wert | Bewertung |
| ----------------- | -------------------- |
| BitFail = 7 | leicht über Schwelle |
| Limit = 0.18 | relativ streng |
| Empfehlung System | **0.28** |
Die Retrain-Empfehlung entsteht fast sicher durch:
```
BitFail > Limit
```
Technisch ist das Modell aber **nicht problematisch**.
Empfehlung:
```
aiConBitFailLimit = 0.22 – 0.25
```
Damit würde der automatische Retrain realistischer arbeiten.
---
# 6. Einfluss der neuen SolarForecast-Version
Die Änderung von **2.3.x** wirkt sich hier vermutlich auf:
* Trainingsdatenaufbereitung
* Feature-Selektion
* Sample-Handling
aus.
Indiz dafür ist:
* deutlich verbesserter **Bias**
* schnelleres **Training (Epoche 208)**.
---
# 7. Modellkapazität
Aktuelle Struktur:
```
Inputs: 98
Hidden: 80-40
Samples: ~7900
```
Parameterabschätzung:
```
98*80 ≈ 7840
80*40 ≈ 3200
40*1 ≈ 40
----------------
~11000 Gewichte
```
Bei ~7900 Samples ist das **noch akzeptabel**, aber bereits relativ dicht.
Das erklärt:
* frühe Konvergenz
* stabile Fehlerwerte.
---
# 8. Gesamtbewertung
| Bereich | Bewertung |
| ------------------- | -------------- |
| Trainingsstabilität | sehr gut |
| Prognosefehler | gut |
| Kalibrierung | **sehr gut** |
| Bias | **fast ideal** |
| Drift | unkritisch |
| Robustheit | gut |
Das Modell ist jetzt **praktisch produktionsreif**.
---
# 9. Empfehlung für deine aktuelle Konfiguration
Deine Parameter sind bereits sinnvoll:
```
ActFunc = GAUSSIAN_SYMMETRIC
HiddenLayers = 80-40
LearnRate = 0.001
Momentum = 0.6
ShuffleMode = 1
TrainAlgo = INCREMENTAL
```
Einzige sinnvolle Anpassung:
```
aiConBitFailLimit 0.23
```
Alles andere würde vermutlich **keinen messbaren Gewinn mehr bringen**.
---
# 10. Fazit
Die Entwicklung über die letzten Trainingsläufe zeigt eine klare Optimierung:
| Training | R² | Bias | RMSE |
| -------------- | -------- | --------- | ---------- |
| Februar Modell | 0.60 | 523 Wh | 443 Wh |
| 01.03 Modell | 0.72 | 404 Wh | 402 Wh |
| 11.03 Modell | **0.72** | **51 Wh** | **408 Wh** |
Der größte Fortschritt ist:
**Die Kalibrierung des Modells ist jetzt nahezu korrekt.**
Damit ist dieses Modell **das bisher beste deiner Reihe**.
---
Wenn du möchtest, kann ich auch noch zeigen, warum gerade bei **Wärmepumpen + PV-Eigenverbrauch** ein
R² von etwa **0.7–0.8 meist die praktische Obergrenze** für solche neuronalen Prognosen ist.
Das hat physikalische Gründe und erklärt, warum dein Modell jetzt bereits ziemlich nahe am Optimum arbeitet.
Zitat von: DS_Starter am 11 März 2026, 17:07:13Möglicherweise ein Missverständnis: Wenn ich consForecastLastDays != 0 setze, dann wird das gesamte Verbrauchsprofil des Vortags auf den Folgetag abgebildet, was in meinen Fall nicht gewünscht ist, da ich einige Überschussverbraucher nicht als solche ausweisen kann. Erzeuge ich einen Dummy-Consumer zur Abbildung (m)eines Grundverbrauchsprofils, dann kann ich diesen Dummy-Consumer in der aktuellen Version von SF nur dann korrekt (mit consForecastLastDays == 0) bei der Verbrauchsprognose berücksichtigen lassen, wenn seine Leistung über den Tag konstant ist.ZitatEs spricht fast nichts dagegen, aber eben nur fast. Denn für die Verbrauchsprognose wird der Verbrauch aller Consumer summiert. Wünschenswert wäre es aber (zumindest in meinem Anwendungsfall), nur die Consumer bei der Verbrauchsprogose zu berücksichtigen, der eine Grundlast darstellen oder aber aktuell geplant sind.Also ich müsste mich nochmal vergewissern, aber ich bin der Meinung, dass nur gaplante oder eingeschaltete Consumer für die Prognose berücksichtigt werden.
...