76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

Begonnen von DS_Starter, 11 Februar 2024, 14:11:00

Vorheriges Thema - Nächstes Thema

DS_Starter

Ja, das sind auch unbestrittene Vorteile. Macht das Leben leichter.  ;)
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

300P

Guten Morgen,

ich hab mal ein Beispiel für eine einfache (ON/OFF) Batteriesteuerung bei den SMA-BWR hier eingestellt.
Logisch ist, das dort ein Modbus-Device für diesen Anwendungsfall vorhanden sein muss bzw. laufen muss.

Hier für die Interessierten noch ein paar Eckdaten :

Modbus ->> Ladebegrenzung dieses BWR einschalten mit 0 Watt:

Set_Leistung_W 0                # Max. Bezug in Watt am Netzübergangspunkt (ADDR 40149)
Set_Aktiv  802                  # Einschalten Kommunikationsregelung (ADDR 40151)
Dieser SET (802) ergibt folgenden Eintrag im BWR-SBS2.5:
10421    Eigenverbrauchsregelung wurde gestoppt

Zum Ausschalten dieser "Blockade" und dem "Einschalten" der normalen SMA-BMS Regelungen....:

Modbus ->>  Ladebegrenzung dieses BWR mit 0 Watt ausschalten:
Ausschalten ("direkt") dann mit ihr kurzer Wartezeit:
Set_Aktiv  803                  # Ausschalten Kommunikationsregelung
Dieser SET (803) ergibt folgenden Eintrag im BWR-SBS2.5:
10420    Eigenverbrauchsregelung wurde gestartet


obj-h40149-expr $val
obj-h40149-len 2
obj-h40149-name SBS25_Set_Leistung_W
obj-h40149-poll once
obj-h40149-reading Set_Leistung_W
obj-h40149-set 1
obj-h40149-unpack I>
obj-h40151-expr $val
obj-h40151-name SBS25_Set_Aktiv
obj-h40151-poll once
obj-h40151-reading Set_Aktiv
obj-h40151-set 1

Gruß
300P

FHEM 6.4|RPi|SMAEM|SMAInverter|SolarForecast| DbLog|DbRep|MariaDB|Buderus-MQTT_EMS|
Fritzbox|fhempy|JsonMod|HTTPMOD|Modbus ser+TCP| ESP32_AI_on_the_Edge|ESP32CAM usw.

300P

Zitat von: DS_Starter am 23 August 2026, 21:15:31Ja, das sind auch unbestrittene Vorteile. Macht das Leben leichter.  ;)

Was ich ganz vergessen habe zu erwähnen:
Mein ,,Server-Energieverbrauch" ist von ca. 1.2 kWh auf ca. 0.95 kWh pro Tag durch den Wegfall des RPI4 und der angeschlossenen USB-SSD gesunken.👀😱
(Qnap/Switche/Fritzbox/DHCP-Server)

Das sind 0.250 kWh/Tag x 365 Tage = 91 kWh weniger beim Jahreshausverbrauch auf dem Zähler....🥳😇.
Gruß
300P

FHEM 6.4|RPi|SMAEM|SMAInverter|SolarForecast| DbLog|DbRep|MariaDB|Buderus-MQTT_EMS|
Fritzbox|fhempy|JsonMod|HTTPMOD|Modbus ser+TCP| ESP32_AI_on_the_Edge|ESP32CAM usw.

TiPpFeHlEr

Hi,

ich habe seit einigen Tagen ein Problem mit berechnung der tatsächlichen erzeugten Solarmenge und Verbrauches.
siehe Bild1.



die Conf sieht folgendermaßen aus
defmod Solarforecast SolarForecast
attr Solarforecast consumer01 SolarTestKlima1 type=heater power=500 mode=can on=on off=off pcurr=Power:W:3 mintime=SunPath:60:-60
attr Solarforecast consumer02 Solar_Heater_Esszimmer type=heater power=500 mode=can on=on off=off pcurr=Power:W interruptable=0 mintime=SunPath:60:-60
attr Solarforecast consumer03 Solar_Heater_Kueche type=heater power=500 mode=can on=on off=off pcurr=Power:W interruptable=0 mintime=SunPath:60:-60
attr Solarforecast consumer04 SolarTestWWB1 type=heater power=2500 mode=can on=on off=off pcurr=Power:W interruptable=1 mintime=SunPath:60:-60
attr Solarforecast consumerControl showLegend=icon_top detailLink=1
attr Solarforecast ctrlLanguage DE
attr Solarforecast disable 0
attr Solarforecast event-on-change-reading .*
attr Solarforecast flowGraphicControl showconsumerpower=1 showconsumerremaintime=1
attr Solarforecast graphicBeam1Color 2DFF03
attr Solarforecast graphicBeam1Content pvReal
attr Solarforecast graphicBeam2Color FF1414
attr Solarforecast graphicBeam2Content pvForecast
attr Solarforecast graphicBeam3Content consumption
attr Solarforecast graphicBeam4Content consumptionForecast
attr Solarforecast graphicHeaderOwnspec Autarkierate:Current_AutarkyRate\
PV übermorgen:special_dayAfterTomorrowPVforecast\
Verbrauch bis<br>Sunset:special_todayConForecastTillSunset\
Verbrauch bis<br>nächsten Sunrise:special_conForecastTillNextSunrise\
\
Anzeige Nachtstunden:graphicShowNight\
hist. Stunden:graphicHistoryHour\
Autokorrektur:pvCorrectionFactor_Auto\
Verbr. Neuplanung:consumerNewPlanning\
Wetteranzeige:graphicShowWeather
attr Solarforecast graphicHistoryHour 6
attr Solarforecast graphicShowNight 1
attr Solarforecast graphicShowWeather 1
attr Solarforecast graphicWeatherColorNight 000091
attr Solarforecast plantControl batteryPreferredCharge=75 cycleInterval=0
attr Solarforecast room Solar
attr Solarforecast setupBatteryDev01 MTEC.Modbus pout=Bat_Leistung:kW pin=-pout cap=10000 charge=battery_soc show=1
attr Solarforecast setupInverterDev01 MTEC.Modbus pvIn=pv:W pvOut=pv:W etotal=pv_total:kWh capacity=10000 strings=Dach,Carport
attr Solarforecast setupInverterStrings Dach,Carport
attr Solarforecast setupMeterDev Stromzaehler gcon=power:W contotal=Energie:kWh gfeedin=-gcon feedtotal=Einspeisung:kWh
attr Solarforecast setupRadiationAPI OpenMeteoDWD-API
attr Solarforecast setupStringAzimuth Dach=0 Carport=0
attr Solarforecast setupStringDeclination Dach=45 Carport=5
attr Solarforecast setupStringPeak Dach=6.0 Carport=4.0
attr Solarforecast setupWeatherDev1 OpenMeteoDWD-API
attr Solarforecast verbose 5

setstate Solarforecast updated
setstate Solarforecast 2026-08-25 17:37:20 .Solarforecast_graphicHistoryHour 6
setstate Solarforecast 2026-08-25 17:37:20 .Solarforecast_graphicShowNight 1
setstate Solarforecast 2026-08-25 17:37:20 .Solarforecast_graphicShowWeather 1
setstate Solarforecast 2026-08-25 17:30:41 .associatedWith Stromzaehler SolarTestKlima1 Solar_Heater_Esszimmer Solar_Heater_Kueche SolarTestWWB1 MTEC.Modbus
setstate Solarforecast 2026-08-25 17:33:51 .lastupdateForecastValues 1787672031
setstate Solarforecast 2026-08-25 17:22:50 .pvCorrectionFactor_Auto_Soll on_simple_ai
setstate Solarforecast 2026-08-25 01:00:04 .signaldone_01 done
setstate Solarforecast 2026-08-25 02:00:04 .signaldone_02 done
setstate Solarforecast 2026-08-25 03:00:04 .signaldone_03 done
setstate Solarforecast 2026-08-25 04:00:05 .signaldone_04 done
setstate Solarforecast 2026-08-25 05:00:05 .signaldone_05 done
setstate Solarforecast 2026-08-25 06:00:04 .signaldone_06 done
setstate Solarforecast 2026-08-25 07:00:04 .signaldone_07 done
setstate Solarforecast 2026-08-25 08:00:05 .signaldone_08 done
setstate Solarforecast 2026-08-25 09:00:04 .signaldone_09 done
setstate Solarforecast 2026-08-25 10:00:04 .signaldone_10 done
setstate Solarforecast 2026-08-25 11:00:04 .signaldone_11 done
setstate Solarforecast 2026-08-25 12:00:04 .signaldone_12 done
setstate Solarforecast 2026-08-25 13:00:04 .signaldone_13 done
setstate Solarforecast 2026-08-25 14:00:04 .signaldone_14 done
setstate Solarforecast 2026-08-25 15:00:04 .signaldone_15 done
setstate Solarforecast 2026-08-25 16:00:05 .signaldone_16 done
setstate Solarforecast 2026-08-25 17:00:04 .signaldone_17 done
setstate Solarforecast 2026-08-25 00:00:04 .signaldone_24 done
setstate Solarforecast 2026-08-25 17:33:51 Battery_ChargeOptTargetPower_01 9223372036854775808 W
setstate Solarforecast 2026-08-25 17:33:51 Battery_ChargeUnrestricted_01 1
setstate Solarforecast 2026-08-25 17:33:51 Battery_TargetAchievable_01 1
setstate Solarforecast 2026-08-25 17:33:51 Current_AutarkyRate 100 %
setstate Solarforecast 2026-08-25 17:33:51 Current_BatCharge_01 99.99 %
setstate Solarforecast 2026-08-25 17:33:51 Current_Consumption 2689 W
setstate Solarforecast 2026-08-25 17:33:51 Current_GridConsumption 0 W
setstate Solarforecast 2026-08-25 17:33:51 Current_GridFeedIn 292 W
setstate Solarforecast 2026-08-25 17:33:51 Current_PV 2981 W
setstate Solarforecast 2026-08-25 17:33:51 Current_PowerBatIn_01 0 W
setstate Solarforecast 2026-08-25 17:33:51 Current_PowerBatOut_01 0 W
setstate Solarforecast 2026-08-25 17:33:51 Current_SelfConsumption 2689 W
setstate Solarforecast 2026-08-25 17:33:51 Current_SelfConsumptionRate 90 %
setstate Solarforecast 2026-08-25 17:33:51 Current_Surplus 292 W
setstate Solarforecast 2026-08-25 17:00:00 LastHourGridconsumptionReal 0 Wh
setstate Solarforecast 2026-08-25 17:00:00 LastHourPVforecast 4300 Wh
setstate Solarforecast 2026-08-25 17:00:00 LastHourPVreal 0 Wh
setstate Solarforecast 2026-08-25 17:33:51 NextHours_Sum01_PVforecast 2146 Wh
setstate Solarforecast 2026-08-25 17:33:51 NextHours_Sum02_PVforecast 3016 Wh
setstate Solarforecast 2026-08-25 17:33:51 NextHours_Sum03_PVforecast 3184 Wh
setstate Solarforecast 2026-08-25 17:33:51 NextHours_Sum04_ConsumptionForecast 2140 Wh
setstate Solarforecast 2026-08-25 17:33:51 NextHours_Sum04_PVforecast 3184 Wh
setstate Solarforecast 2026-08-25 17:33:51 RestOfDayConsumptionForecast 2140 Wh
setstate Solarforecast 2026-08-25 17:33:51 RestOfDayPVforecast 3184 Wh
setstate Solarforecast 2026-08-25 17:33:51 Today_CONdeviation -199.51 %
setstate Solarforecast 2026-08-25 17:33:51 Today_CONforecast 22360 Wh
setstate Solarforecast 2026-08-25 17:33:51 Today_CONreal 81170 Wh
setstate Solarforecast 2026-08-25 00:59:49 Today_Hour01_BatIn_01 0 Wh
setstate Solarforecast 2026-08-25 00:59:49 Today_Hour01_BatOut_01 0 Wh
setstate Solarforecast 2026-08-25 00:59:49 Today_Hour01_GridConsumption 0 Wh
setstate Solarforecast 2026-08-25 00:59:49 Today_Hour01_GridFeedIn 10 Wh
setstate Solarforecast 2026-08-25 00:59:49 Today_Hour01_PVreal 0 Wh
setstate Solarforecast 2026-08-25 01:59:49 Today_Hour02_BatIn_01 0 Wh
setstate Solarforecast 2026-08-25 01:59:49 Today_Hour02_BatOut_01 0 Wh
setstate Solarforecast 2026-08-25 01:59:49 Today_Hour02_GridConsumption 0 Wh
setstate Solarforecast 2026-08-25 01:59:49 Today_Hour02_GridFeedIn 10 Wh
setstate Solarforecast 2026-08-25 01:59:49 Today_Hour02_PVreal 0 Wh
setstate Solarforecast 2026-08-25 02:59:49 Today_Hour03_BatIn_01 0 Wh
setstate Solarforecast 2026-08-25 02:59:49 Today_Hour03_BatOut_01 0 Wh
setstate Solarforecast 2026-08-25 02:59:49 Today_Hour03_GridConsumption 0 Wh
setstate Solarforecast 2026-08-25 02:59:49 Today_Hour03_GridFeedIn 10 Wh
setstate Solarforecast 2026-08-25 02:59:49 Today_Hour03_PVreal 0 Wh
setstate Solarforecast 2026-08-25 03:59:49 Today_Hour04_BatIn_01 0 Wh
setstate Solarforecast 2026-08-25 03:59:49 Today_Hour04_BatOut_01 0 Wh
setstate Solarforecast 2026-08-25 03:59:49 Today_Hour04_GridConsumption 10 Wh
setstate Solarforecast 2026-08-25 03:59:49 Today_Hour04_GridFeedIn 10 Wh
setstate Solarforecast 2026-08-25 03:59:49 Today_Hour04_PVreal 0 Wh
setstate Solarforecast 2026-08-25 04:59:49 Today_Hour05_BatIn_01 0 Wh
setstate Solarforecast 2026-08-25 04:59:49 Today_Hour05_BatOut_01 0 Wh
setstate Solarforecast 2026-08-25 04:59:49 Today_Hour05_GridConsumption 0 Wh
setstate Solarforecast 2026-08-25 04:59:49 Today_Hour05_GridFeedIn 10 Wh
setstate Solarforecast 2026-08-25 04:59:49 Today_Hour05_PVreal 0 Wh
setstate Solarforecast 2026-08-25 05:59:49 Today_Hour06_BatIn_01 0 Wh
setstate Solarforecast 2026-08-25 05:59:49 Today_Hour06_BatOut_01 0 Wh
setstate Solarforecast 2026-08-25 05:59:49 Today_Hour06_GridConsumption 10 Wh
setstate Solarforecast 2026-08-25 05:59:49 Today_Hour06_GridFeedIn 10 Wh
setstate Solarforecast 2026-08-25 05:59:49 Today_Hour06_PVreal 0 Wh
setstate Solarforecast 2026-08-25 06:59:49 Today_Hour07_BatIn_01 0 Wh
setstate Solarforecast 2026-08-25 06:59:49 Today_Hour07_BatOut_01 0 Wh
setstate Solarforecast 2026-08-25 06:59:49 Today_Hour07_GridConsumption 0 Wh
setstate Solarforecast 2026-08-25 06:59:49 Today_Hour07_GridFeedIn 10 Wh
setstate Solarforecast 2026-08-25 06:59:49 Today_Hour07_PVforecast 180 Wh
setstate Solarforecast 2026-08-25 06:59:49 Today_Hour07_PVreal 2000 Wh
setstate Solarforecast 2026-08-25 07:59:49 Today_Hour08_BatIn_01 0 Wh
setstate Solarforecast 2026-08-25 07:59:49 Today_Hour08_BatOut_01 0 Wh
setstate Solarforecast 2026-08-25 07:59:49 Today_Hour08_GridConsumption 0 Wh
setstate Solarforecast 2026-08-25 07:59:49 Today_Hour08_GridFeedIn 10 Wh
setstate Solarforecast 2026-08-25 07:59:49 Today_Hour08_PVforecast 640 Wh
setstate Solarforecast 2026-08-25 07:59:49 Today_Hour08_PVreal 5000 Wh
setstate Solarforecast 2026-08-25 08:59:49 Today_Hour09_BatIn_01 0 Wh
setstate Solarforecast 2026-08-25 08:59:49 Today_Hour09_BatOut_01 0 Wh
setstate Solarforecast 2026-08-25 08:59:49 Today_Hour09_GridConsumption 10 Wh
setstate Solarforecast 2026-08-25 08:59:49 Today_Hour09_GridFeedIn 10 Wh
setstate Solarforecast 2026-08-25 08:59:49 Today_Hour09_PVforecast 2317 Wh
setstate Solarforecast 2026-08-25 08:59:49 Today_Hour09_PVreal 0 Wh
setstate Solarforecast 2026-08-25 09:59:49 Today_Hour10_BatIn_01 0 Wh
setstate Solarforecast 2026-08-25 09:59:49 Today_Hour10_BatOut_01 0 Wh
setstate Solarforecast 2026-08-25 09:59:49 Today_Hour10_GridConsumption 0 Wh
setstate Solarforecast 2026-08-25 09:59:49 Today_Hour10_GridFeedIn 320 Wh
setstate Solarforecast 2026-08-25 09:59:49 Today_Hour10_PVforecast 4069 Wh
setstate Solarforecast 2026-08-25 09:59:49 Today_Hour10_PVreal 8000 Wh
setstate Solarforecast 2026-08-25 10:59:49 Today_Hour11_BatIn_01 0 Wh
setstate Solarforecast 2026-08-25 10:59:49 Today_Hour11_BatOut_01 0 Wh
setstate Solarforecast 2026-08-25 10:59:49 Today_Hour11_GridConsumption 0 Wh
setstate Solarforecast 2026-08-25 10:59:49 Today_Hour11_GridFeedIn 3160 Wh
setstate Solarforecast 2026-08-25 10:59:49 Today_Hour11_PVforecast 5500 Wh
setstate Solarforecast 2026-08-25 10:59:49 Today_Hour11_PVreal 12000 Wh
setstate Solarforecast 2026-08-25 11:59:49 Today_Hour12_BatIn_01 0 Wh
setstate Solarforecast 2026-08-25 11:59:49 Today_Hour12_BatOut_01 0 Wh
setstate Solarforecast 2026-08-25 11:59:49 Today_Hour12_GridConsumption 0 Wh
setstate Solarforecast 2026-08-25 11:59:49 Today_Hour12_GridFeedIn 4260 Wh
setstate Solarforecast 2026-08-25 11:59:49 Today_Hour12_PVforecast 6600 Wh
setstate Solarforecast 2026-08-25 11:59:49 Today_Hour12_PVreal 13000 Wh
setstate Solarforecast 2026-08-25 12:59:49 Today_Hour13_BatIn_01 0 Wh
setstate Solarforecast 2026-08-25 12:59:49 Today_Hour13_BatOut_01 0 Wh
setstate Solarforecast 2026-08-25 12:59:49 Today_Hour13_GridConsumption 0 Wh
setstate Solarforecast 2026-08-25 12:59:49 Today_Hour13_GridFeedIn 4870 Wh
setstate Solarforecast 2026-08-25 12:59:49 Today_Hour13_PVforecast 7178 Wh
setstate Solarforecast 2026-08-25 12:59:49 Today_Hour13_PVreal 14000 Wh
setstate Solarforecast 2026-08-25 13:59:49 Today_Hour14_BatIn_01 0 Wh
setstate Solarforecast 2026-08-25 13:59:49 Today_Hour14_BatOut_01 0 Wh
setstate Solarforecast 2026-08-25 13:59:49 Today_Hour14_GridConsumption 0 Wh
setstate Solarforecast 2026-08-25 13:59:49 Today_Hour14_GridFeedIn 5190 Wh
setstate Solarforecast 2026-08-25 13:59:49 Today_Hour14_PVforecast 7022 Wh
setstate Solarforecast 2026-08-25 13:59:49 Today_Hour14_PVreal 0 Wh
setstate Solarforecast 2026-08-25 14:59:49 Today_Hour15_BatIn_01 0 Wh
setstate Solarforecast 2026-08-25 14:59:49 Today_Hour15_BatOut_01 0 Wh
setstate Solarforecast 2026-08-25 14:59:49 Today_Hour15_GridConsumption 10 Wh
setstate Solarforecast 2026-08-25 14:59:49 Today_Hour15_GridFeedIn 5740 Wh
setstate Solarforecast 2026-08-25 14:59:49 Today_Hour15_PVforecast 6908 Wh
setstate Solarforecast 2026-08-25 14:59:49 Today_Hour15_PVreal 12000 Wh
setstate Solarforecast 2026-08-25 15:59:50 Today_Hour16_BatIn_01 0 Wh
setstate Solarforecast 2026-08-25 15:59:50 Today_Hour16_BatOut_01 0 Wh
setstate Solarforecast 2026-08-25 15:59:50 Today_Hour16_GridConsumption 0 Wh
setstate Solarforecast 2026-08-25 15:59:50 Today_Hour16_GridFeedIn 4110 Wh
setstate Solarforecast 2026-08-25 15:59:50 Today_Hour16_PVforecast 4500 Wh
setstate Solarforecast 2026-08-25 15:59:50 Today_Hour16_PVreal 6000 Wh
setstate Solarforecast 2026-08-25 16:59:51 Today_Hour17_BatIn_01 0 Wh
setstate Solarforecast 2026-08-25 16:59:51 Today_Hour17_BatOut_01 0 Wh
setstate Solarforecast 2026-08-25 16:59:51 Today_Hour17_GridConsumption 0 Wh
setstate Solarforecast 2026-08-25 16:59:51 Today_Hour17_GridFeedIn 1990 Wh
setstate Solarforecast 2026-08-25 16:59:51 Today_Hour17_PVforecast 4300 Wh
setstate Solarforecast 2026-08-25 16:59:51 Today_Hour17_PVreal 0 Wh
setstate Solarforecast 2026-08-25 17:33:51 Today_Hour18_BatIn_01 0 Wh
setstate Solarforecast 2026-08-25 17:33:51 Today_Hour18_BatOut_01 0 Wh
setstate Solarforecast 2026-08-25 17:33:51 Today_Hour18_GridConsumption 0 Wh
setstate Solarforecast 2026-08-25 17:33:51 Today_Hour18_GridFeedIn 850 Wh
setstate Solarforecast 2026-08-25 17:33:51 Today_Hour18_PVforecast 2963 Wh
setstate Solarforecast 2026-08-25 17:33:51 Today_Hour18_PVreal 16000 Wh
setstate Solarforecast 2026-08-25 17:33:51 Today_Hour19_PVforecast 1478 Wh
setstate Solarforecast 2026-08-25 17:33:51 Today_Hour20_PVforecast 373 Wh
setstate Solarforecast 2026-08-25 17:33:51 Today_MaxPVforecast 7178 Wh
setstate Solarforecast 2026-08-25 17:33:51 Today_MaxPVforecastTime 2026-08-25 12:00:00
setstate Solarforecast 2026-08-25 17:33:51 Today_PVforecast 54028 Wh
setstate Solarforecast 2026-08-25 17:33:51 Today_PVreal 88000 Wh
setstate Solarforecast 2026-08-25 17:33:51 Today_SunRise 06:08
setstate Solarforecast 2026-08-25 17:33:51 Today_SunSet 20:15
setstate Solarforecast 2026-08-25 17:33:51 Tomorrow_CONforecast 22495 Wh
setstate Solarforecast 2026-08-25 17:33:51 Tomorrow_PVforecast 30747 Wh
setstate Solarforecast 2026-08-25 17:33:51 Tomorrow_SunRise 06:10
setstate Solarforecast 2026-08-25 17:33:51 Tomorrow_SunSet 20:13
setstate Solarforecast 2026-08-25 17:33:51 consumer01 name='SolarTestKlima1' state='on' mode='can' planningstate='started'
setstate Solarforecast 2026-08-25 17:33:51 consumer01_currentPower 1.3 W
setstate Solarforecast 2026-08-25 17:33:51 consumer01_planned_start 25.08.2026 08:45:47
setstate Solarforecast 2026-08-25 17:33:51 consumer01_planned_stop 25.08.2026 19:14:59
setstate Solarforecast 2026-08-25 17:33:51 consumer02 name='Solar_Heater_Esszimmer' state='on' mode='can' planningstate='started'
setstate Solarforecast 2026-08-25 17:33:51 consumer02_currentPower 0 W
setstate Solarforecast 2026-08-25 17:33:51 consumer02_planned_start 25.08.2026 08:45:47
setstate Solarforecast 2026-08-25 17:33:51 consumer02_planned_stop 25.08.2026 19:14:59
setstate Solarforecast 2026-08-25 17:33:51 consumer03 name='Solar_Heater_Kueche' state='on' mode='can' planningstate='started'
setstate Solarforecast 2026-08-25 17:33:51 consumer03_currentPower 0 W
setstate Solarforecast 2026-08-25 17:33:51 consumer03_planned_start 25.08.2026 08:45:47
setstate Solarforecast 2026-08-25 17:33:51 consumer03_planned_stop 25.08.2026 19:14:59
setstate Solarforecast 2026-08-25 17:33:51 consumer04 name='SolarTestWWB1' state='on' mode='can' planningstate='continued'
setstate Solarforecast 2026-08-25 17:33:51 consumer04_currentPower 2000 W
setstate Solarforecast 2026-08-25 17:33:51 consumer04_planned_start 25.08.2026 08:59:47
setstate Solarforecast 2026-08-25 17:33:51 consumer04_planned_stop 25.08.2026 19:14:59
setstate Solarforecast 2026-08-25 17:35:09 nextCycletime Manual / Event-controlled
setstate Solarforecast 2026-08-25 17:19:53 nextRadiationAPICall nach 25.08.2026 17:34:53
setstate Solarforecast 2026-08-25 07:00:04 pvCorrectionFactor_07 1.00 (automatic - old factor: 0.96, AI result used, Days in range: 158)
setstate Solarforecast 2026-08-25 08:00:05 pvCorrectionFactor_08 0.93 (automatic - old factor: 0.91, AI result used, Days in range: 194)
setstate Solarforecast 2026-08-25 10:00:04 pvCorrectionFactor_10 0.96 (automatic - old factor: 0.96, Days in range: 225)
setstate Solarforecast 2026-08-25 11:00:04 pvCorrectionFactor_11 0.99 (automatic - old factor: 0.98, AI result used, Days in range: 224)
setstate Solarforecast 2026-08-25 12:00:04 pvCorrectionFactor_12 0.93 (automatic - old factor: 0.93, AI result used, Days in range: 224)
setstate Solarforecast 2026-08-25 13:00:04 pvCorrectionFactor_13 0.94 (automatic - old factor: 0.93, Days in range: 224)
setstate Solarforecast 2026-08-25 15:00:04 pvCorrectionFactor_15 0.93 (automatic - old factor: 0.93, Days in range: 224)
setstate Solarforecast 2026-08-25 16:00:05 pvCorrectionFactor_16 0.91 (automatic - old factor: 0.91, AI result used, Days in range: 224)
setstate Solarforecast 2026-08-25 17:35:45 pvCorrectionFactor_Auto on_complex_ai
setstate Solarforecast 2026-08-25 17:33:52 state updated

Was kann das sein?

die Echtzeitdaten zB. von pv sehen so aus Bild2
es gibt also von der PV keine seltsamen (falschen) Daten.

Gruß



300P

Schau mal nach:

du hast immer wieder PVreal Stundenwerte mit 0 wh.
...
und danach sind die Werte dann ca. doppelt so hoch ;)
->>> Das ist schon sehr ungewöhnlich bei dem heutigen Wetter....
setstate Solarforecast 2026-08-25 13:59:49 Today_Hour14_PVforecast 7022 Wh
setstate Solarforecast 2026-08-25 13:59:49 Today_Hour14_PVreal 0 Wh
....
setstate Solarforecast 2026-08-25 14:59:49 Today_Hour15_PVforecast 6908 Wh
setstate Solarforecast 2026-08-25 14:59:49 Today_Hour15_PVreal 12000 Wh

setstate Solarforecast 2026-08-25 08:59:49 Today_Hour09_PVforecast 2317 Wh
setstate Solarforecast 2026-08-25 08:59:49 Today_Hour09_PVreal 0 Wh
.....
setstate Solarforecast 2026-08-25 09:59:49 Today_Hour10_PVforecast 4069 Wh
setstate Solarforecast 2026-08-25 09:59:49 Today_Hour10_PVreal 8000 Wh
Da werden die Werte evtl. nicht immer übermittelt / zur Verfügung gestellt... ???

Prüf deshalb mal dein Abfrage-Device zu BWR/WR sehr genau nach.

Und:
ist das richtig mit den Einheiten hier:
Bitte sehr GENAU hinsehen!
(Müsste aber okay sein - da deine Grafik dies so zeigt)
attr Solarforecast setupBatteryDev01 MTEC.Modbus pout=Bat_Leistung:kW pin=-pout cap=10000 charge=battery_soc show=1
attr Solarforecast setupInverterDev01 MTEC.Modbus pvIn=pv:W pvOut=pv:W etotal=pv_total:kWh capacity=10000 strings=Dach,Carport
attr Solarforecast setupInverterStrings Dach,Carport
attr Solarforecast setupMeterDev Stromzaehler gcon=power:W contotal=Energie:kWh gfeedin=-gcon feedtotal=Einspeisung:kWh
Gruß
300P

FHEM 6.4|RPi|SMAEM|SMAInverter|SolarForecast| DbLog|DbRep|MariaDB|Buderus-MQTT_EMS|
Fritzbox|fhempy|JsonMod|HTTPMOD|Modbus ser+TCP| ESP32_AI_on_the_Edge|ESP32CAM usw.

Mexx13

Betreff: KI-Verbrauchsprognose massiv schlechter seit Update (v2.6.10→2.10.1) + Bug in _aiFannAutoArchitecture (Zeile ~38506)

Hallo zusammen,

ich melde mich mit einer Mischung aus Bug-Report und offener Frage. Bis Version 2.6.10 lief das KI-Training bei mir sehr gut – seit dem Update auf 2.10.1 ist die Prognosequalität massiv eingebrochen, trotz aktuell "ok"-Bewertung aller Einzelmetriken im Modul. Ich komme trotz mehrerer Tage Fehlersuche nicht mehr auf das alte Niveau und wollte hier meine komplette Analyse teilen – vielleicht hilft's anderen oder jemand erkennt, was ich übersehe.

Setup: Fronius GEN24 Hybrid, BYD-Batterie, 2 PV-Strings, Ochsner Wärmepumpe (nur Warmwasser, Modbus TCP) als consumer03.

Der zentrale Befund – direkter Vergleich alt vs. neu:

Metrik   21.06.2026 (v2.6.10-Ära)    Aktuell (26.08.2026, v2.10.1)
R²               0.84                    0.24–0.31
Slope            0.88                    0.47–0.48
MAE              82 Wh                   180 Wh
MedAE            32.8 Wh                 78–94 Wh
RMSE relative    56% (acceptable)        110–114% (weak)
MAPE             29.4%                   91–112%
Bias             24 Wh                   190–244 Wh
Inputs           71                      87–109
Architektur      80-40-20            8 (durch DPR-Limit erzwungen)
Trainingsdaten   3432                    5013

Interessant: Auch damals zeigte das Modul schon eine DPR-Warnung ("mit 71 Inputs und nur 2745 Trainingsdaten lässt sich das Verhältnis nicht erreichen"), trotzdem war das Modell exzellent (R²=0.84). Heute ist die DPR "ok" bewertet (7.03), aber das Modell liefert deutlich schlechtere Ergebnisse. Das spricht dagegen, dass die DPR/Architektur der entscheidende Faktor ist – ich vermute eher eine Veränderung an der Feature-Zusammensetzung oder den Trainingsdaten selbst zwischen den Versionen.

Fund 1 – Code-Bug (Shadowing) in _aiFannAutoArchitecture:

Beim Debuggen einer Perl-Warning im Log

PERL WARNING: Use of uninitialized value $x in sprintf at ./FHEM/76_SolarForecast.pm line 38506.

bin ich auf folgendes gestoßen (Zeile ~30252 ff., Version 2.10.1):

perl
sub _aiFannAutoArchitecture {
  my ($num_train_datasets, $num_inputs, $ratio_min) = @_;
  my @candidates = ('128-64-32', '64-32-16', '64-32', '32-16', '16-8', '16', '12', '8');
  my $dataParamRatio;                                    # äußere Deklaration

  for my $arch (@candidates) {
    my $num_params = __aiFannEstimateParams($num_inputs, $arch);
    my $dataParamRatio = $num_train_datasets / $num_params;   # <-- "my" hier erneut!
    return ($arch, $dataParamRatio) if $dataParamRatio >= $ratio_min;
  }

  return ('8', $dataParamRatio);   # äußere, nie beschriebene Variable -> undef
}

Das zweite my in der Schleife deklariert eine neue, lokale Variable und verdeckt die äußere. Solange eine Kandidaten-Architektur ratio_min erreicht, fällt es nicht auf. Erreicht keine Architektur die Ratio, läuft die Schleife komplett durch und der finale Return gibt die nie beschriebene äußere Variable zurück → undef. Bei mir reproduzierbar aufgetreten, als die Inputs bei 109 lagen und keine Kandidaten-Architektur die Mindest-Ratio erreichte.

Fund 2 – Systematischer Hyperparameter-Vergleich (jeweils 1 Parameter geändert, Rest konstant), alle mit v2.10.1:

Test          Epoche (von 15000) R²     MAE    Bias
LR=0.0006, BitFail=0.34   360     0.27    173.5   197
LR=0.0001, BitFail=0.34   357     0.31    180.2   244
LR=0.0001, BitFail=0.25   1919    0.24    180.0   205
+ SIGMOID_SYMMETRIC   1199    0.24    180.0   190

Auffällig: Die vom Modul vorgeschlagene Lernraten-Anpassung hatte praktisch keinen Effekt auf die Epochenausnutzung (357 vs. 360 trotz 6-facher LR-Reduktion). Erst das BitFail-Limit brachte spürbar mehr Epochen (357→1919), aber ohne messbare Verbesserung von R²/MAE. Der Wechsel der Aktivierungsfunktion (SIGMOID→SIGMOID_SYMMETRIC) brachte ebenfalls keine Veränderung. Slope bleibt bei allen Varianten bei ~0.47-0.48 – weit unter dem historischen Wert von 0.88. Das bestätigt für mich: Hyperparameter-Tuning allein bringt hier nichts, das Problem liegt woanders.

Zusätzlich fiel auf: Die "Einstellhinweise" des Moduls empfahlen bei einem Lauf eine Reduktion der Lernrate, beim nächsten (fast identisches Ergebnis) eine Erhöhung – wirkte für mich etwas widersprüchlich.

Wo ich jetzt stehe:
Ich bin ehrlich gesagt etwas ratlos. Alle Einzelmetriken werden vom Modul aktuell als "ok" bewertet (DPR ok, Trainingsbewertung ok), aber das reale Ergebnis (R², MAE, Slope) ist himmelweit von dem entfernt, was ich mit v2.6.10 hatte. Das "ok" des Moduls scheint sich auf Trainingsstabilität zu beziehen, nicht auf die tatsächliche Prognosequalität.

Fragen an die Runde:

Ist das Shadowing in _aiFannAutoArchitecture bekannt? Sieht nach einem einfachen Fix aus (zweites my entfernen).
Gibt es zwischen der v2.6.10-Ära und heute strukturelle Änderungen an der Feature-Zusammensetzung/Normierung für die Verbrauchsprognose, die eine derart deutliche Qualitätsverschlechterung erklären könnten?
Hat jemand ähnliche Erfahrungen gemacht – DPR/Trainingsbewertung "ok", aber reale Prognosequalität (R², Slope) deutlich schlechter als in älteren Versionen?

Danke fürs Draufschauen und Verständnis für die etwas lange Ausführung – wollte lieber zu viel Kontext liefern als zu wenig.
Max
Fronius Gen24 8.0 Plus, BYD HVM 11.0, Ochner Europa 333 Genius, USR W630 Modbus RTU to TCP, Fritzbox
Raspberry PI, DB-Log, Open-VPN, Jeelink-LaCrosse, Signalduino-WH1080, Busware SCC, CUL 868MHz -Homematic, ESP8266,...

Shadow3561

Moin,
Was bedeutet diese log-Meldung?
PV_forecast - Execute command to manage the data storage: aiData delValue=con>=12000Gruss

300P

Zitat von: Shadow3561 am 26 August 2026, 05:47:58Moin,
Was bedeutet diese log-Meldung?
PV_forecast - Execute command to manage the data storage: aiData delValue=con>=12000Gruss

Du hast Con-Werte > 12000 gelöscht 😉🤔
Gruß
300P

FHEM 6.4|RPi|SMAEM|SMAInverter|SolarForecast| DbLog|DbRep|MariaDB|Buderus-MQTT_EMS|
Fritzbox|fhempy|JsonMod|HTTPMOD|Modbus ser+TCP| ESP32_AI_on_the_Edge|ESP32CAM usw.

DS_Starter

#6908
Moin,

@Mexx13, danke für den Hinweis bzgl. der PERL WARNING, da ist einfach ein "my" zuviel. Ändere ich ab.

Bezüglich der Unterschiede von 2.6.10 bis 2.10.1 hole ich etwas weiter aus. Da ist viel passiert und wer nicht ständig die Entwicklung und Diskussionen verfolgt, kann verständlicherweise den Faden verlieren oder Fragezeichen im Kopf haben.

Vorab die Kernaussage, danach die Begründung im Detail:

Der Rückgang der Metriken zwischen 2.6.10 und 2.10.1 ist kein Bug, sondern eine korrigierte Datenleckage (Data Leakage) im Trainingsprozess. Die Werte, die du mit 2.6.10 gesehen hast (R²=0.84, Slope=0.88), waren strukturell nicht erreichbar – sie kamen zustande, weil das Modell teilweise Zugriff auf Informationen aus der Zielstunde selbst hatte.


Was war die Leckage und was ist das überhaupt?

Bis 2.6.10 sind bei einem Teil der Feature-Berechnung Werte aus derselben Stunde eingeflossen, die auch die Zielgröße (Verbrauch in Stunde i) ist – statt konsequent nur auf i-1 oder ältere Lags zurückzugreifen. Für ein Vorhersagemodell ist das ein Blick in die Zukunft: Das Netz "lernt" nicht, aus der Vergangenheit die Zukunft zu schätzen, sondern nutzt eine mit dem Ziel korrelierte Größe, die zum Vorhersagezeitpunkt real gar nicht vorliegt. Das erklärt auch, warum die alte DPR-Warnung ("mit 71 Inputs und 2745 Trainingsdaten nicht erreichbar") *trotzdem* zu einem exzellenten Ergebnis führte: Data-Parameter-Ratio und Architekturgröße sind für die Generalisierungsfähigkeit relevant, aber wenn eine Zielleckage vorliegt, hebelt das diesen ganzen Mechanismus aus – das Netz muss dann gar nicht generalisieren, es kann quasi abschreiben. Genau deshalb war die DPR damals kein guter Prädiktor für die tatsächliche Qualität.

Ab 2.6.10 wurde diese Lag-1-Disziplin konsequent durchgesetzt: Jedes von der Zielstunde abgeleitete Feature muss i-1 oder älter sein. Das betrifft alle seither eingeführten Feature-Familien (BEV, Wärmepumpen-Opmode, stochastische Haushalts-Features) genauso wie die Altbestände. Die Folge: Das Modell bekommt strukturell weniger "Information", weil die künstlich verfügbare Zukunftsinformation wegfällt – und die Metriken sinken, obwohl das Modell *besser*, nämlich ehrlich, arbeitet. Allerdings konnte das Modell bis 2.6.10 Vorhersagefehler durch "Nachziehen" in Folgestunden korrigieren, was jetzt nicht mehr passiert.


Einordnung deiner aktuellen Werte

Für stochastische Haushalte (Verbrauch ohne stark dominante, gut vorhersagbare Muster), liegt der nach Leckage-Bereinigung ehrlich erreichbare Bereich bei etwa R²≈0.26, Slope≈0.35. Das ist keine willkürliche Hausnummer, sondern das, was strukturell übrig bleibt, wenn man dem Modell nur noch Vergangenheitsdaten gibt.

Deine aktuellen Werte (R²=0.24–0.31, Slope=0.47–0.48) liegen in genau diesem Rahmen – die Slope ist sogar spürbar besser als der reine Baseline-Wert. Auch dein Bias von 190–244 Wh passt ins Bild: Es gilt näherungsweise

Bias ≈ mean(Verbrauch) × (1 − Slope)

d.h. Bias und Slope sind bei einem strukturell unterbestimmten Problem keine zwei unabhängigen "Fehler", sondern zwei Ausdrucksformen derselben Ursache. Eine Slope von 0.47 bei einem für dich typischen Stundenmittel bedeutet zwangsläufig einen Bias in dieser Größenordnung – das ist rechnerisch konsistent, nicht ein zusätzliches, separates Problem.


Warum das Hyperparameter-Tuning nichts brachte

Lernrate, BitFail-Limit und Aktivierungsfunktion beeinflussen, wie effizient das Netz das aus den Daten Lernbare extrahiert – nicht, wie viel Information in den Daten überhaupt steckt. Wenn die Zielgröße stochastisch ist und keine Leckage mehr vorliegt, gibt es ab einem gewissen Punkt schlicht kein weiteres Signal mehr zu finden, das Slope oder R² nennenswert heben könnte. Mehr Epochen bei gleichbleibendem Ergebnis (357→1919 ohne R²/MAE-Verbesserung) ist genau das erwartbare Symptom eines Deckeneffekts, nicht eines schlecht konfigurierten Trainings.


Zum Anstieg der Input-Anzahl (71 → 87–109)

Das ist kein Nebeneffekt der Leckage-Korrektur, sondern kommt aus dem seit 2.6.10 schrittweise ausgerollten Feature-Umfang (u.a. BEV- und Wärmepumpen-Opmode-Features, stochastische Haushalts-Features). Bei dir mit consumer03 als Wärmepumpe greifen davon vermutlich die Opmode-bezogenen Blöcke. Das ist separat zu der Leckage-Frage zu sehen, wirkt aber in dieselbe Richtung: mehr Inputs bei gleicher Datenmenge senkt die Data-Parameter-Ratio zusätzlich und zwingt (siehe unten) in deinem Fall zur minimalen Architektur.


Zur DPR und dem Standardwert 8

Kurz zur Einordnung, was diese Zahl bedeutet und was nicht: Der Mindestwert (Standard '8') ist eine Sicherheitsschwelle gegen Overfitting, keine Garantie für Prognosequalität. Die Faustregel – ein neuronales Netz sollte pro Parameter ein Vielfaches an Trainingsbeispielen sehen, damit es das Muster lernt statt die Trainingsdaten auswendig zu speichern – liegt in der Literatur meist im Bereich 5–10×. Als praxistaugliche Untergrenze für den produktiven Einsatz hat sich intern ~7× als Minimum herauskristallisiert; der Standardwert 8 liegt bewusst leicht darüber, um noch etwas Puffer zu haben, ohne die Architektur unnötig zu beschneiden.

Das Ganze steuert also nur das Risiko, dass ein Netz mit zu vielen Parametern bei zu wenig Daten die Trainingsdaten memoriert statt zu generalisieren. Es sagt nichts darüber aus, ob überhaupt genug Signal in den Daten steckt, um eine hohe Vorhersagegüte zu erreichen. Das erklärt den scheinbaren Widerspruch in deiner Beobachtung: DPR "ok" (7.03, aktuell) und DPR "nicht erreichbar" (damals) sind zwei Aussagen über unterschiedliche Dinge – Overfitting-Risiko versus tatsächliche Prognosequalität. Ein Modell kann DPR-technisch einwandfrei und trotzdem – bei einem inhärent schwer vorhersagbaren Verbrauchsverhalten – nur mittelmäßige R²/Slope-Werte liefern. Das ist bei dir aktuell der Fall, und es ist der ehrliche, erwartbare Zustand.

Ein Nebeneffekt, den ich mir vormerke: Bei dir zwingt die gestiegene Input-Zahl (87–109) das Modul in die minimale Architektur '8', weil keine größere Architektur die Ratio-8-Schwelle mehr erreicht. Das ist aktuell korrektes Verhalten, aber ich sehe darin einen Punkt, den ich mittelfristig noch genauer anschauen möchte – ob bei stark gestiegener Feature-Dimension eine leicht großzügigere Übergangsregel sinnvoll wäre, damit man nicht zu abrupt in die kleinstmögliche Architektur fällt. Das ist aber eine Optimierung, kein Fix für dein aktuelles Problem.


Zu den scheinbar widersprüchlichen Lernraten-Hinweisen

Kannst du die beiden konkreten Läufe (mit aiConTrainState bzw. den Diagnose-Hints) posten?
Das ist unabhängig von der Leckage-Frage und könnte tatsächlich eine Ungenauigkeit in der Hint-Logik sein, die ich mir isoliert ansehen würde.


Zusammengefasst

Die von dir gemessene Verschlechterung ist real, aber sie ist der Preis für ein Modell, das tatsächlich vorhersagt statt (unbemerkt) zurückblickt. Die alten Werte waren zu gut, um wahr zu sein – im wörtlichen Sinn. Dein aktuelles Ergebnis liegt im für einen stochastischen Haushalt mit Wärmepumpe strukturell erwartbaren Rahmen. Das schließt nicht aus, dass sich durch besseres Feature-Engineering (z.B. bessere Wärmepumpen-Zustandsmerkmale) oder mehr Trainingsdaten noch etwas herausholen lässt – aber die Zeiten von R²=0.84 wird man ohne erneute Leckage nicht mehr sehen, und das ist gut so.

Danke nochmal für den detaillierten Report – falls du magst, schicke mir gerne noch die beiden Hint-Ausgaben zur Lernraten-Frage, das schaue ich mir separat an.

LG,
Heiko
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Shadow3561

Zitat von: 300P am 26 August 2026, 09:28:57
Zitat von: Shadow3561 am 26 August 2026, 05:47:58Moin,
Was bedeutet diese log-Meldung?
PV_forecast - Execute command to manage the data storage: aiData delValue=con>=12000Gruss

Du hast Con-Werte > 12000 gelöscht 😉🤔
Ich Trottel.
Habe vor sehr langer Zeit mal ein at erstellt was die Aussreisser löscht. Jetzt habe ich eine Wallbox und die Werte sind realistisch. Werde mein at anpassen.
Danke für deine Expertise.
Gruß

Mexx13

Hallo Heiko,
danke für die ausführliche Erklärung – das erklärt tatsächlich einiges, was ich zuerst als Rückschritt interpretiert hatte. Macht Sinn, und dass die Werte "zu gut um wahr zu sein" waren, leuchtet mir jetzt ein.
Hier die beiden Trainingsreports zur Lernraten-Frage:

Lauf 1 (LR=0.0006):
Lernverhalten: sehr früh konvergiert (2.4 % Epochenausnutzung)
Einstellhinweise:
* Lernrate zu hoch: Lernrate (aiControl->aiConLearnRate) um Faktor 5-10 reduzieren (z.B. von 0.01 auf 0.001-0.002)

Hyperparameter: Learning Rate=0.0006, Momentum=0.5, BitFail-Limit=0.34
Architektur: Inputs=87, Hidden Layers=8, Outputs=1
bestes Modell bei Epoche: 360 (max. 15000)
R²: 0.27


Lauf 2 (LR=0.0001, direkt danach, sonst unverändert):
Lernverhalten: sehr früh konvergiert (2.4 % Epochenausnutzung)
Einstellhinweise:
Lernrate bereits am unteren Limit (0.0001) – Netz konvergiert dennoch sehr früh.
In manchen Fällen hilft hier ausnahmsweise eine moderate Erhöhung der Lernrate
(z.B. +50-100%) in Kombination mit passend abgestimmtem Momentum (aktuell 0.50),
um ein flaches Plateau zu verlassen.

Hyperparameter: Learning Rate=0.0001, Momentum=0.5, BitFail-Limit=0.34
Architektur: Inputs=87, Hidden Layers=8, Outputs=1
bestes Modell bei Epoche: 357 (max. 15000)
R²: 0.31

Auffällig: identische Epochenausnutzung (2.4%) bei beiden, trotz 6-facher Lernraten-Differenz – aber der Hinweis sagt beim ersten Mal "runter", beim zweiten Mal (mit fast gleichem Ergebnis) "rauf". Vielleicht hilft das bei der Einordnung, ob da eine Kleinigkeit in der Hint-Logik justiert werden muss.
Danke nochmal für die Mühe mit der ausführlichen Antwort!
Fronius Gen24 8.0 Plus, BYD HVM 11.0, Ochner Europa 333 Genius, USR W630 Modbus RTU to TCP, Fritzbox
Raspberry PI, DB-Log, Open-VPN, Jeelink-LaCrosse, Signalduino-WH1080, Busware SCC, CUL 868MHz -Homematic, ESP8266,...

DS_Starter

Hallo Mexx13,

danke für deine Infos. Was es mir zeigt:

Lauf 1 (LR=0.0006) und Lauf 2 (LR=0.0001) landen beide im selben Diagnose-Zweig ("sehr früh konvergiert"), weil die Epochenausnutzung bei beiden bei nur 2.4 % lag. Innerhalb dieses Zweigs prüft die Diagnose, ob die Lernrate bereits am konfigurierten unteren Limit (0.0001) angekommen ist:

Lauf 1: LR=0.0006 liegt über dem Limit -> "Lernrate zu hoch, reduzieren" wird vorgeschlagen.
Lauf 2: LR=0.0001 liegt exakt am Limit -> die "Lernrate reduzieren"-Empfehlung wird bewusst unterdrückt und stattdessen ein alternativer Hinweis ("ausnahmsweise moderate Erhöhung versuchen") ausgegeben.

Diese beiden Hinweise schließen sich also durch eine explizite Prüfung gegenseitig aus und sind kein Zufallsprodukt – das Modul hat lediglich erkannt, dass eine weitere Reduktion nicht mehr sinnvoll ist, weil sie am Boden angekommen war. Die Sachfrage für das Modul geht in Richtung Plateau -> eine höhere Lernrate kann im Training das Verlassen eines Plateaus herbeiführen, womit der Prozess erstmal richtig in den Lernporzess kommt. Das klingt erstmal nach Widerspruch, aber man erkennt mit etwas Übung im Trainingslog sehr schnell wenn "der Knoten platzt".

Interessanter ist etwas anderes: Beide Läufe landen bei praktisch identischer Epochenzahl (360 bzw. 357), obwohl die Lernrate um Faktor 6 verändert wurde – das allein deutet schon darauf hin, dass die Lernrate hier gar nicht die Ursache für die frühe Konvergenz war. Dein Zusatzversuch mit dem verschärften BitFail-Limit bestätigt das: Ein strengeres Zielkriterium (0.34 -> 0.25) erhöhte die genutzte Epochenzahl deutlich (357->1919) – ohne messbare Verbesserung von R² oder MAE. Das zeigt, dass das Netz bei dieser Architektur/Feature-Kombination bereits ausgeschöpft hat, was es lernen konnte; das frühe Erreichen des (laxeren) BitFail-Ziels war der eigentliche Auslöser des Stopps, nicht ein Lernraten-Problem.

Die aktuelle Diagnoselogik unterscheidet bei "früh konvergiert" aber nicht zwischen "Ziel erreicht, weil die Architektur/Datenlage das Limit hergibt" und "Training stagniert trotz nicht erreichtem Ziel" – beides führt zu denselben LR-/Momentum-Hinweisen. Genau das hat bei dir zu Empfehlungen geführt, die zwar in sich stimmig, aber in deinem Fall wirkungslos waren, weil die eigentliche Grenze durch Architektur (minimal, DPR-bedingt) und Feature-Kapazität gesetzt war, nicht durch die Trainingsdynamik.

Für mich als Konsequenz:
Ich baue dafür eine zusätzliche Erkennung ein: Wenn früh konvergiert wird, das R² dabei unter der Profilschwelle bleibt und die Architektur nicht überdimensioniert ist (DPR im normalen Bereich, nicht "zu groß für die Datenmenge"), wird künftig kein LR-/Momentum-Hinweis mehr ausgegeben, sondern ein eigener Hinweis, der auf die Kapazitätsgrenze von Architektur/Feature-Set verweist und stattdessen zu Feature-Erweiterung bzw. – sofern die Datenlage es zulässt – einer größeren Architektur rät. Das muß ich mir aber noch in Ruhe durchdenken, wird aber im nächsten Release mit drin sein. Zur Info - Feature Erweiterung bzw. Verringerung geht im Modul nicht direkt, sondern über den Umweg der Wahl des passenden aiConProfile.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter