76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[300P]

Mit der letzten Version und einigen Anpassungen der Parameter aiCon* hat sich jetzt ein "relativ" gutes Ergebnis seit 2 Tagen bei mir eingependelt.

Code Auswählen Erweitern

Informationen zum neuronalen Netz der Verbrauchsvorhersage

letztes KI-Training: 13.01.2026 03:20:19 / Laufzeit in Sekunden: 3604
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 63.12 ms
Verbrauchernummer Wärmepumpe: 08

=== Modellparameter ===

Normierungsgrenzen: PV=16071 Wh, Hausverbrauch: Min=0 Wh / Max=7598 Wh
Trainingsdaten: 7013 Datensätze (Training=5610, Validierung=1403)
Architektur: Inputs=108, Hidden Layers=64-32, Outputs=1
Hyperparameter: Learning Rate=0.001, Momentum=0.2, BitFail-Limit=0.35
Aktivierungen: Hidden=GAUSSIAN, Steilheit=1.5, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Registry Version=v1_heatpump_active_pv
Zufallsgenerator: Mode=1, Periode=15

=== Trainingsmetriken ===

bestes Modell bei Epoche: 1905 (von max. 15000)
Training MSE: 0.002047
Validation MSE: 0.007452
Validation MSE Average: 0.010264
Validation MSE Standard Deviation: 0.000228
Validation Bit_Fail: 0
Model Bias: 601 Wh
Model Slope: 0.6
Trainingsbewertung: Retrain

=== Fehlermaße der Prognosen ===

MAE: 501.66 Wh
MedAE: 370.47 Wh
RMSE: 616.07 Wh
RMSE relative: 27 %
RMSE Rating: weak
MAPE: 21.64 %
MdAPE: 18.92 %
R²: 0.41

=== Drift-Kennzahlen ===

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


Nur unsere "Kochorgie" heute Mittag konnte sicherlich niemand vorhersehen...


Aktuelle Einstellungen / Parameter:

Code Auswählen Erweitern

attr Forecast aiControl aiTrainStart=3 \
aiStorageDuration=3600 \
aiTreesPV=30 \
aiConActivate=1 \
aiConAlpha=0.4\
aiConTrainStart=7:2 \
aiConActFunc=GAUSSIAN \
aiConHiddenLayers=64-32 \
aiConLearnRate=0.001 \
aiConMomentum=0.2 \
aiConShuffleMode=1 \
aiConShufflePeriod=15 \
aiConSteepness=1.5 \
aiConTrainAlgo=INCREMENTAL \
aiConProfile=v1_heatpump_active_pv

[DS_Starter]

Da sollte auch kein Hinweis kommen wenn "FF" mit dabei ist, nur wenn's fehlt

Genau, wenn es fehlt kommt im Systemcheck die Meldung wie im Anhang zu sehen.

[stefanru]

Das macht aber kein Sinn ich habe FF drin und die Daten im DWD Device enthalten auch FF:
forecastProperties SunUp, SunRise, SunSet, Rad1h, R101, TTT, Tx, Tn, Tg, DD, FX1, RR1c, RR6c, R600, RRhc, Rh00, ww, wwd, Neff, FF

Ich sehe die Daten im Solarcast nicht und bekomme die Zeile im Check?

[DS_Starter]

@Stefan,
du hast FF gesetzt und bekommst im Check auch ein "ok" -> alles gut.
Die Daten siehst du z.B. mit "get .. nextHours" -> Key windspeed:

Code Auswählen Erweitern

NextHour00 => starttime: 2026-01-13 17:00:00, day: 13, weekday: Di, hourofday: 18, today: 1
              pvapifcraw: 0, pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0
              conlegfc: 146, conaifc: -, confc: 146, confcEx: 146, weatherid: 103, wcc: 93, rr1c: 0.00
              temp: 3.30, windspeed: 13.00, rad1h: 0, sunaz: 247, sunalt: -9, DoN: 0
              rrange: 0.00, crange: -, DaysInRange: -, correff: 1.00/0.08
              soc01: 87.0, soc02: 50.4, soc03: -, socprogwhsum: 6869
              rcdchargebat01: 1, rcdchargebat02: 1, rcdchargebat03: -
              lcintimebat01: 1, lcintimebat02: 1, lcintimebat03: -
              strategybat01: optPower, strategybat02: optPower, strategybat03: -
NextHour01 => starttime: 2026-01-13 18:00:00, day: 13, weekday: Di, hourofday: 19, today: 1
              pvapifcraw: 0, pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0
              conlegfc: 172, conaifc: -, confc: 172, confcEx: 172, weatherid: 103, wcc: 94, rr1c: 0.00
              temp: 3.10, windspeed: 13.00, rad1h: 0, sunaz: 258, sunalt: -18, DoN: 0
              rrange: 0.00, crange: -, DaysInRange: -, correff: 1.00/0.01
              soc01: 83.8, soc02: 47.3, soc03: -, socprogwhsum: 6557
              rcdchargebat01: 1, rcdchargebat02: 1, rcdchargebat03: -
              lcintimebat01: 1, lcintimebat02: 1, lcintimebat03: -
              strategybat01: optPower, strategybat02: optPower, strategybat03: -
NextHour02 => starttime: 2026-01-13 19:00:00, day: 13, weekday: Di, hourofday: 20, today: 1
              pvapifcraw: 0, pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0
              conlegfc: 138, conaifc: -, confc: 138, confcEx: 138, weatherid: 103, wcc: 93, rr1c: 0.00
              temp: 3.40, windspeed: 13.00, rad1h: 0, sunaz: 269, sunalt: -27, DoN: 0
              rrange: 0.00, crange: -, DaysInRange: -, correff: 1.00/0.14
              soc01: 81.3, soc02: 44.8, soc03: -, socprogwhsum: 6307
              rcdchargebat01: 1, rcdchargebat02: 1, rcdchargebat03: -
              lcintimebat01: 1, lcintimebat02: 1, lcintimebat03: -
              strategybat01: optPower, strategybat02: optPower, strategybat03: -
....

Was genau ist jetzt dein Problem?

[stefanru]

Ach so 
Ich dachte das wird in der Grafik angezeigt.
War auch erstaunt warum.
Fließt der Windspeed in die Berechnung für WP ein? Oder für was ist er gut?

Danke für die Erklärung Heiko.

Gruß,
Stefan

[DS_Starter]

Es war ein Anliegen von Klaus Schauer. Aber ja, wenn ich die WP Kalkulation auch in meine Legacy-VB Prognose einbauen will, kommt windspeed dort mit hinein.

[Wolle02]

Hier mal das Schaubild wie sich die Prognose entwickelt hat als ich heute ab 15h mein EV geladen habe. Die grauen Balken um 16, 17 und 18 h hat das System erst nachträglich "hochgeregelt" als es gemerkt hat "Hoppla, da wird jetzt aber mehr Strom gezogen als ich gedacht habe". Vorher waren die Balken auch so um die 700.

Ich nehme mal an, dass auch noch ein Trigger für den SoC vom EV eingebaut wird, damit die KI das besser prognostizieren kann?

[DS_Starter]

Ich nehme mal an, dass auch noch ein Trigger für den SoC vom EV eingebaut wird, damit die KI das besser prognostizieren kann?

Ja EV kommt noch, da ist noch nichts passiert.

[DS_Starter]

@lorisurfen,

Laut meinem debug von gestern wird aber swoncond nur beim erstmaligen einschalten geprüft, nicht aber nach interruptable ?
Ich hätte erwartet, wenn über Schlüssel interruptable unterbrochen wird, dann beim (Wieder-)Einschalten auch swoncond geprüft/erfüllt sein muss?

Nein, das sind zwei verschiedene Sachverhalte. Der Prozess mal in Kürze:

- zunächst wird der Consumer gemäß seine Vorgaben geplant
- Ist die Startzeit der Planung erreicht UND es liegen die definierten Voraussetzungen wie
  PV-Überschuß UND die definierte swoncond=true! vor, wird der Consumer tatsächlich gestartet.
  Damit ist die Aufgabe von swoncond erfüllt, d.h. es ist eine Bedingung die erfüllt sein muß um
  den geplanten Prozess zu starten
- nach dem Start bis zum geplanten Ende kann der Consumer durch interruptable unterbrochen bzw.
  weitergeführt werden, sobald die Interuptbedingung nicht mehr vorliegt.
- Der gesamte Zyklus des Consumers wird beendet (finished) wenn entweder das geplante Ende erreicht ODER
  eine gesetzte Bedingung swoffcond=true ist.

Ist das ein Fehler oder kann ich das irgendwie einstellen, dass nach interruptable auch swoncond geprüft wird.

Nein, weder ein Fehler noch einstellbar. Siehe oben.

Ist Prüfung auf swoncond evtl. unterschiedlich bei interruptable=1 und interruptable=Bedingung?

Wie oben beschrieben sind es zwei verschiedene Sachverhalte.
 

Nach swoffcond und einem replan (Sofortige Neueinplanung) würde dagegen doch auch swoncond erneut geprüft (Für meinen Fall möchte ich immer, dass beim Wiedereinschalten auch swoncond geprüft wird).

Das ist so, ja.

Entweder muss nach interruptable auch swoncond geprüft werden oder die folgende Aussage wäre nicht zutreffend?
...

Der Kontext war, dass man einen beendeten Zyklus durch einen Schlüssel replan=1 immer sofort wieder neu einplant. Unter dem Vorbehalt, dass der User immer auch eine swoncond definiert, die steuernd eingreift, hast du recht. Allerdings kann interruptable auch {Perl-Code} verarbeiten, sodass hier auch komplexere Bedingungen abgebildet werden könnten.
Wie geschrieben, kann ich replan=1 einbauen, aber es gibt auch bereits jetzt diverse Möglichkeiten eine solche Funktionalität abzubilden.

[300P]

Wenn das PV- / und CO-Ergebnis von heute und gestern nur das ganze Jahr so weiter gehen "würde"       

[lorisurfen]

@lorisurfen,

ich habe nochmal über deinen Fall siniert und bin der Meinung, so wie du es eingestellt hast hätte der Consumer ausschalten müssen. Auch wenn nur 90% PV Leistung verlangt ist, sollte er ausschalten wenn Suplus=0 ist!

Ich habe im Modul etwas angepasst und auch die Debug-Ausgabe erweitert damit man mehr sieht in diesem Fall:

2026.01.11 18:07:09.503 1: SolCast DEBUG> ############### consumerSwitching consumer "06" ###############
2026.01.11 18:07:09.504 1: SolCast DEBUG> consumer "06" - ConsumptionRecommended calc method: default, surplus: 0
2026.01.11 18:07:09.504 1: SolCast DEBUG> consumer "06" - current Grid power consumption: 24 W
2026.01.11 18:07:09.504 1: SolCast DEBUG> consumer "06" - Power splitting - Grid: 12, PV: 0
2026.01.11 18:07:09.505 1: SolCast DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 0 W
...

Ziehe dir bitte die Version 2.0.0 aus meinem contrib (siehe Fußtext), restarte FHEM und dann schauen wir nochmal ob die Raktionen dann so sind wie erwartet.

Hallo Heiko,
Danke erstmal für die neue Version und den support, habe mir die Version 2.0.0 runtergeladen und man sieht jetzt im folgenden debug, sobald surplus auf 0 geht wird ausgeschaltet:
Wobei Grid cosumption ist auch 0. Werden bei pvshare = 90 maximal 10% aus dem Netz oder der Batterie geholt?
Wenn also Energie in der Batterie werden statt Grid max 10% aus der Batterie geholt (Current_PowerBatOut_01 max 100W ?) ?

Code Auswählen Erweitern

2026.01.12 10:56:49 1: SF01 DEBUG> ############### consumerSwitching consumer "06" ###############
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - ConsumptionRecommended calc method: default, surplus: 240
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - current Grid power consumption: 25 W
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - Power splitting - Grid: 100 W, PV: 900 W
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 0 W
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - current planning state: continued
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - physical Switchstate before switching: on
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - logical Switchstate before switching: on
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 1253 W, nompower: 1000, surplus: 240 W, planstate: continued:, starttime: 12.01.2026 10:36:26
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - isInLocktime: 0
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 0, on-command: on
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - isAddSwitchOnCond Info: The return value "0" resulted in 'false' after exec "{$VALUE>500?1:0;}"

2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - device 'Shelly_EG_2' is used as switching device
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - Interrupt Characteristic value: 1 -> simple true
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - is Consumption recommended: 1
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - current planning state: continued
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - physical Switchstate after switching: on
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - logical Switchstate after switching: on
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - cycleDayNum: 4
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - last cycle start time: 2026-01-12 10:38:14
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - last cycle end time: still running

2026.01.12 10:56:52 1: SF01 DEBUG> ############### consumerSwitching consumer "06" ###############
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - ConsumptionRecommended calc method: default, surplus: 0
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - current Grid power consumption: 0 W
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - Power splitting - Grid: 100 W, PV: 900 W
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 0 W
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - current planning state: continued
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - physical Switchstate before switching: on
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - logical Switchstate before switching: on
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 1577 W, nompower: 1000, surplus: 0 W, planstate: continued:, starttime: 12.01.2026 10:36:26
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - isInLocktime: 0
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 0, on-command: on
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - isAddSwitchOnCond Info: The return value "0" resulted in 'false' after exec "{$VALUE>500?1:0;}"

2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - device 'Shelly_EG_2' is used as switching device
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - Interrupt Characteristic value: 1 -> simple true
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - is Consumption recommended: 0
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - send switch command now: "set Shelly_EG_2 off"
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - current planning state: interrupting
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - physical Switchstate after switching: on
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - logical Switchstate after switching: on
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - cycleDayNum: 4
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - last cycle start time: 2026-01-12 10:38:14
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - last cycle end time: still running

[DS_Starter]

Wobei Grid cosumption ist auch 0. Werden bei pvshare = 90 maximal 10% aus dem Netz oder der Batterie geholt?
Wenn also Energie in der Batterie werden statt Grid max 10% aus der Batterie geholt (Current_PowerBatOut_01 max 100W ?) ?

Bei der Aufteilung pvshare geht es rein um den Netzbezug im Verhältnis zu PV-Energie. Energie aus der Batterie ist in unserem Kontext nichts anderes als
gespeicherte PV Energie und wird als solche angesehen.
Wenn also ein Consumer sich zu 10% von 1000W = 100W max. aus dem Netz bedienen darf, würde er unterbrochen bzw. nicht wieder eingeschaltet wenn diese Bedingung
verletzt werden würde.